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Formally  establishing  safety  properties  of  software  presents  a  grand  challenge  to  the 
computer  science  community  Producing  proof-carrying  code,  i.e.,  machine  code  with 
machine-checkable  specifications  and  proofs,  is  particularly  difficult  for  system  softwares 
written  in  low-level  languages.  One  central  problem  is  the  lack  of  verification  theories 
that  can  handle  the  expressive  power  of  low-level  code  in  a  modular  fashion.  In  partic¬ 
ular,  traditional  type-  and  logic-based  verification  approaches  have  restrictions  on  either 
expressive  power  or  modularity. 

This  dissertation  presents  XCAP,  a  logic-based  proof-carrying  code  framework  for 
modular  machine  code  verification.  In  XCAP,  program  specifications  are  written  as  gen¬ 
eral  logic  predicates,  in  which  syntactic  constructs  are  used  to  modularly  specify  some 
crucial  higher-order  programming  concepts  for  system  code,  including  embedded  code 
pointers,  impredicative  polymorphisms,  recursive  invariants,  and  general  references,  all 
in  a  logical  setting.  Thus,  XCAP  achieves  the  expressive  power  of  logic-based  approaches 
and  the  modularity  of  type-based  approaches.  Its  meta  theory  has  been  completely  mech¬ 
anized  and  proved. 

XCAP  can  be  used  to  directly  certify  system  kernel  code.  This  dissertation  contains 
a  mini  certified  thread  library  written  in  x86  assembly.  Every  single  instruction  in  the 
library,  including  those  for  context  switching  and  thread  scheduling,  has  a  formal  XCAP 
specification  and  a  proof.  XCAP  is  also  connected  to  existing  certifying  compiler;  a  type¬ 
preserving  translation  from  a  typed  assembly  language  to  XCAP  is  included. 


Report  Documentation  Page 


Form  Approved 
OMB  No.  0704-0188 


Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 
VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 


1.  REPORT  DATE 

MAY  2007 


2.  REPORT  TYPE 


3.  DATES  COVERED 

00-00-2007  to  00-00-2007 


5a.  CONTRACT  NUMBER 


5b.  GRANT  NUMBER 


5c.  PROGRAM  ELEMENT  NUMBER 


5d.  PROJECT  NUMBER 


5e.  TASK  NUMBER 


5f.  WORK  UNIT  NUMBER 


4.  TITLE  AND  SUBTITLE 

Modular  Machine  Code  Verification 


6.  AUTHOR(S) 


7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES)  8.  PERFORMING  ORGANIZATION 

Yale  University  , Department  of  Computer  Science, New  report  number 

Haven, CT, 06520-8285 

9.  SPONSORING/MONITORING  AGENCY  NAME(S )  AND  ADDRESS(ES )  10.  SPONSOR/MONITOR' S  ACRONYM(S) 

11.  SPONSOR/MONITOR'S  REPORT 
NUMBER(S) 

12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 

13.  SUPPLEMENTARY  NOTES 

14.  ABSTRACT 

Formally  establishing  safety  properties  of  software  presents  a  grand  challenge  to  the  computer  science 
community.  Producing  proof-carrying  code,  i.e.,  machine  code  with  machine-checkable  specifications  and 
proofs,  is  particularly  difficult  for  system  softwares  written  in  low-level  languages.  One  central  problem  is 
the  lack  of  verification  theories  that  can  handle  the  expressive  power  of  low-level  code  in  a  modular 
fashion.  In  particular,  traditional  type-  and  logic-based  verification  approaches  have  restrictions  on  either 
expressive  power  or  modularity.  This  dissertation  presents  XCAP,  a  logic-based  proof-carrying  code 
framework  for  modular  machine  code  verification.  In  XCAP,  program  specifications  are  written  as  general 
logic  predicates,  in  which  syntactic  constructs  are  used  to  modularly  specify  some  crucial  higher-order 
programming  concepts  for  system  code,  including  embedded  code  pointers,  impredicative  polymorphisms, 
recursive  invariants,  and  general  references,  all  in  a  logical  setting.  Thus,  XCAP  achieves  the  expressive 
power  of  logic-based  approaches  and  the  modularity  of  type-based  approaches.  Its  meta  theory  has  been 
completely  mechanized  and  proved.  XCAP  can  be  used  to  directly  certify  system  kernel  code.  This 
dissertation  contains  a  mini  certified  thread  library  written  in  x86  assembly.  Every  single  instruction  in  the 
library,  including  those  for  context  switching  and  thread  scheduling,  has  a  formal  XCAP  specification  and 
a  proof.  XCAP  is  also  connected  to  existing  certifying  compiler;  a  typepreserving  translation  from  a  typed 
assembly  language  to  XCAP  is  included. 

15.  SUBJECT  TERMS 


16.  SECURITY  CLASSIFICATION  OF: 

17.  LIMITATION  OF 

18.  NUMBER 

19a.  NAME  OF 

ABSTRACT 

OF  PAGES 

RESPONSIBLE  PERSON 

a.  REPORT 

unclassified 

b.  ABSTRACT 

unclassified 

c.  THIS  PAGE 

unclassified 

Same  as 
Report  (SAR) 

183 

Modular  Machine  Code  Verification 


A  Dissertation 

Presented  to  the  Faculty  of  the  Graduate  School 

of 

Yale  University 

in  Candidacy  for  the  Degree  of 
Doctor  of  Philosophy 


By 

Zhaozhong  Ni 


Dissertation  Director:  Zhong  Shao 


May  2007 


Copyright  ©  2007  by  Zhaozhong  Ni 
All  rights  reserved. 


Contents 


Acknowledgments  vii 

1  Introduction  1 

1.1  Machine  Code  Verification .  2 

1.2  Previous  Work .  4 

1.3  Challenges  and  Contributions .  6 

2  Background  11 

2.1  The  Target  Machine .  11 

2.2  Mechanized  Meta  Logic .  13 

2.3  The  Certified  Assembly  Programming  Framework .  16 

3  Embedded  Code  Pointers  and  the  Basic  XCAP  Framework  21 

3.1  Embedded  Code  Pointers .  22 

3.2  Extended  Propositions .  27 

3.3  The  XCAP  Framework .  30 

3.4  Discussion .  34 

4  Impredicative  Polymorphisms  and  Recursive  Specifications  37 

4.1  Impredicative  Polymorphisms  and  Recursive  Specifications  .  38 

4.2  Solving  Reynolds's  ECP  Problem .  42 

4.3  Recursive  Specifications .  47 


i 


4.4  Discussion 


48 


5  Weak  Updates  and  a  Translation  from  Typed  Assembly  Language  51 

5.1  Weak  Update  in  the  Logical  Setting .  52 

5.2  Typed  Assembly  Language  (TAL) .  54 

5.3  A  "Semantic"  TAL  Language .  58 

5.4  Translations  from  TAL /STAL  to  XCAP .  61 

5.5  Discussion .  64 

6  A  Port  to  x86  Machine  67 

6.1  Mini86:  a  Subset  of  the  x86  Architecture .  67 

6.2  XCAP86:  a  Port  of  XCAP  on  Mini86  .  71 

6.3  Verification  of  a  polymorphic  queue  module  .  80 

7  A  Certified  Mini  Thread  Library  85 

7.1  MTH:  A  Mini  Thread  Library .  86 

7.2  Verification  of  the  Machine  Context  Module .  90 

7.3  Verification  of  the  Threading  Module .  96 

7.4  Discussion . 107 

8  The  Coq  Implementations  109 

8.1  Implementation  of  PropX  . 110 

8.2  Implementation  of  XCAP  . 114 

8.3  Implementation  of  XCAP86 . 116 

8.4  Implementation  of  MTH . 119 

9  Conclusion  and  Future  Work  121 

9.1  Conclusion . 121 

9.2  Trusted  Computing  Base . 122 

9.3  Comparison  with  the  Indexed  Approach . 125 

ii 


9.4  Future  Work 


127 


A  PropX  Validity  Soundness  Proof  133 

B  XCAP  Soundness  Proof  141 

C  TAL  to  XCAP  Translation  Typing  Preservation  Proof  147 

D  XCAP86  Soundness  Proof  155 

Bibliography  163 


iii 


IV 


List  of  Figures 


2.1  Syntax  of  target  machine .  12 

2.2  Operational  semantics  of  target  machine .  13 

2.3  Mechanized  meta  logic .  14 

2.4  Assertion  language  of  CAP  .  17 

2.5  Inference  rules  of  CAP .  18 

3.1  Extended  propositions .  29 

3.2  Interpretations  of  extended  propositions .  29 

3.3  Assertion  language  of  XCAP .  31 

3.4  Inference  rules  of  XCAP .  32 

4.1  Validity  rules  for  impredicative  extended  propositions  .  39 

4.2  Code,  specification,  and  illustration  of  the  list  append  function .  45 

4.3  Code,  specification,  and  illustration  of  the  list  append  function  (continued)  46 

5.1  Type  definitions  of  TAL  .  55 

5.2  Top-level  static  semantics  of  TAL .  56 

5.3  Static  semantics  of  TAL  (subtyping  and  instruction  typing) .  57 

5.4  Static  semantics  of  TAL  (state  and  value  typing)  .  59 

5.5  Translations  from  TAL  types  to  XCAP  predicates .  62 

6.1  Mini86  execution  environment .  68 

6.2  Mini86  syntax .  69 


v 


6.3  Dynamic  semantics  of  Mini86 .  70 

6.4  Syntax  of  XCAP86 .  72 

6.5  Validity  rules  of  XCAP86  extended  propositions .  73 

6.6  Inference  rules  of  XCAP86 .  75 

6.7  Function  calling  convention .  78 

6.8  Verification  of  queue  insertion .  82 

6.9  Verification  of  queue  deletion .  83 

7.1  Module  structure  and  pseudo-C  specification  of  MTH .  87 

7.2  Threading  model  of  MTH .  88 

7.3  Machine  context .  90 

7.4  Verification  of  machine  context  switching .  93 

7.5  Verification  of  machine  context  loading  .  94 

7.6  Verification  of  machine  context  creation .  95 

7.7  Thread  control  blocks  and  queues  of  MTH .  96 

7.8  Threading  invariant  of  MTH .  97 

7.9  Verification  of  thread  yielding . 100 

7.10  Verification  of  thread  creation . 101 

7.11  Verification  of  thread  creation  (continued) . 102 

7.12  Verification  of  thread  termination . 103 

7.13  Verification  of  thread  initialization . 104 

7.14  Verification  of  thread  scheduler . 105 

7.15  Verification  of  thread  scheduler  (continued) . 106 

A.l  Assertion  language  of  the  full-featured  XCAP . 134 

A.2  Validity  rules  for  extended  propositions  of  the  full-featured  XCAP . 135 

A.3  Normal  natural  deduction  validity  rules . 137 

A.4  Sequent  style  validity  rules  . 138 


vi 


Acknowledgments 


The  first  person  I  want  to  thank  is  my  advisor.  Professor  Zhong  Shao.  Entering  the  PhD 
program  six  years  ago,  I  had  little  idea  about  what  it  would  actually  take  to  finish  this  dis¬ 
sertation.  It  is  Professor  Shao's  encouraging  advices  and  thoughtful  guidance  that  helped 
and  supported  my  pursuit  of  this  exciting  research.  He  patiently  taught  me  knowledge 
and  trained  my  skills  starting  with  the  very  basics.  From  day  one,  he  has  been  amazingly 
good  at  pushing  me  towards  working  with  him  more  as  a  colleague  than  as  a  student.  I 
remember  and  appreciate  all  the  lively  discussions,  exciting  discoveries,  as  well  as  dis¬ 
appointing  failures  and  sometimes  heated  debates  I  shared  with  him  during  the  past  six 
years.  I  truly  learned  a  lot  from  his  broad  vision  on  research,  persistency  in  deep  under¬ 
standing,  and  ever-lasting  enthusiasm. 

I  have  been  very  lucky  to  have  overlap  with  every  other  member  of  the  FLINT  group  in 
its  first  ten  years.  Valery  Trifonov  was  extremely  helpful  to  my  PhD  study,  especially  dur¬ 
ing  the  first  few  years.  Bra  tin  Saha,  Christopher  League,  and  Stefan  Monnier  answered 
many  of  my  naive  questions  in  the  early  years.  I  had  close  and  pleasant  collaborations 
with  Dachuan  Yu,  Nadeem  A.  Hamid,  and  Xinyu  Feng.  Entering  the  PhD  program  in 
the  same  year,  Hai  Fang  and  I  discussed  and  exchanged  our  experiences  and  frustrations 
during  the  various  stages  of  the  study.  I  also  enjoyed  the  discussions  with  Andrew  Mc- 
Creight,  Rodrigo  Ferreira,  and  Alexander  Vaynberg. 

°This  research  is  based  on  work  supported  in  part  by  gifts  from  Intel  and  Microsoft,  DARPA  OASIS  grant 
F30602-99-1-0519,  NSF  grant  CCR-9901011,  NSF  ITR  grant  CCR-0081590,  and  NSF  grant  CCR-0524545.  Any 
opinions,  findings,  and  conclusions  contained  in  this  document  are  those  of  the  authors  and  do  not  reflect  the 
views  of  these  agencies. 


vii 


I  would  like  to  thank  Professor  Paul  Hudak,  Professor  Carsten  Schtirmann,  and  Pro¬ 
fessor  David  Walker  for  serving  on  my  thesis  committee  and  being  my  thesis  readers. 
Professor  Paul  Hudak  taught  me  a  formal  semantics  course  and  has  been  very  helpful  to 
my  study  in  the  PhD  program.  Professor  Carsten  Schtirmann  taught  me  my  first  formal 
method  course  and  gave  me  many  advices,  especially  in  my  first  year.  Professor  David 
Walker  gave  me  many  instructional  advices  and  had  very  helpful  interactions  with  me  on 
my  research  progress. 

I  would  also  like  to  thank  Professor  Drew  McDermott  and  Professor  Yang  R.  Yang  for 
their  help  in  my  graduate  study.  I  want  to  thank  Linda  Dobb  and  Judy  Smith,  who  helped 
me  with  all  the  administrative  stuffs. 

Finally,  I  would  like  to  thank  my  parents  and  my  family,  without  the  support  from 
which  the  completion  of  my  graduate  study  and  this  dissertation  would  be  impossible.  I 
am  especially  grateful  to  my  wife,  Zhiyan,  whose  love,  care,  and  support  are  my  source 
of  energy  along  the  journey. 


viii 


Chapter  1 


Introduction 


We  begin  this  dissertation  with  the  following  code: 
swapcontext : 


;  save  old  context 
mov  eax,  [esp+4] 

;  load  new  context 
mov  eax,  [esp+8] 

mov 

[eax+_eax] , 

0 

mov 

esp, 

[eax+_esp] 

mov 

[eax+_ebx] , 

ebx 

mov 

ebp, 

[eax+_ebp] 

mov 

[eax+_ecx] , 

ecx 

mov 

edi , 

[eax+_edi] 

mov 

[eax+_edx] , 

edx 

mov 

esi , 

[eax+_esi] 

mov 

[eax+_esi] , 

esi 

mov 

edx, 

[eax+_edx] 

mov 

[eax+_edi] , 

edi 

mov 

ecx, 

[eax+_ecx] 

mov 

[eax+_ebp] , 

ebp 

mov 

ebx, 

[eax+_ebx] 

mov 

[eax+_esp] , 

esp 

mov 

ret 

eax, 

[eax+_eax] 

This  19  lines  of  x86  assembly  code  constitutes  a  common  routine  for  machine-context 
switching,  omitting  floating-point  and  special  registers.  The  first  (left)  half  of  the  code 
saves  the  current  machine  context,  whereas  the  second  (right)  half  loads  the  new  machine 
context  and  resumes  execution  from  there.  Being  executed  virtually  every  millisecond  on 
most  PCs,  code  sequences  similar  to  this  are  a  crucial  part  of  modern  OS. 

Surprisingly,  despite  the  simplicity  and  small  size  of  this  piece  of  code,  to  the  author's 
knowledge,  it  has  never  been  rigorous  proved  to  be  safe  and  correct,  whether  manually  or 
automatically.  There  is  not  even  a  rigorous  statement  on  what  this  19  lines  of  code  should 
and  should  not  do.  In  fact,  this  seemingly  simple  code  sequence  turns  out  to  be  extremely 
difficult  to  specify  and  reason  about.  The  lack  of  safety  guarantee  at  such  a  core  of  OS 
kernel  makes  any  claim  about  software  safety  and  security  a  "wish"  instead  of  reality. 
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1.1  Machine  Code  Verification 


Program  correctness  or,  to  a  less  degree,  code  safety,  has  long  been  one  of  the  most  de¬ 
sired  goals  for  computer  programmers  and  users.  With  great  dependency  on  information 
technology  in  the  modern  world,  individuals  and  businesses  are  getting  more  concerned 
about  the  reliability  and  the  security  of  the  computing  infrastructure  than  ever.  Great 
efforts  and  investments  have  been  put  into  the  research  and  development  of  software  ver¬ 
ification  tools  for  a  long  time.  In  [32],  formally  establishing  safety  properties  of  software 
has  been  identified  as  a  grand  challenge  to  the  computer  science  community. 

From  the  point  of  view  of  software  engineering,  there  are  many  levels  of  program 
abstractions.  At  the  top  level  are  algorithms  and  protocols,  which  normally  get  imple¬ 
mented  in  various  high-level  programming  languages  (including  domain-specific  lan¬ 
guages),  the  later  of  which  often  get  translated  into  and  are  supported  by  intermediate 
languages  found  either  in  compilers  or  in  portable  virtual  machines.  In  the  end  there 
is  assembly  and  machine  code,  which  carries  out  the  actual  computations  and  provides 
critical  runtime  support. 

Surprisingly,  in  the  entire  hierarchy  of  program  verification  there  is  one  important 
level  that  receives  much  less  attention  than  the  others.  Despite  the  fact  that  all  higher 
level  abstraction  and  verification  efforts  will  eventually  be  based  upon  the  machine  code 
level,  there  have  been  much  fewer  existing  works  done  in  machine  code  verification.  The 
direct  result  of  the  lack  of  machine  code  level  verification  support  is  that  most  of  the  safe 
algorithms/protocols/programs  usually  lose  their  safety  guarantees  when  being  imple¬ 
mented  or  translated  into  binary. 

Recently,  formal  studies  on  critical  code  such  as  OS  kernels  are  attracting  growing  in¬ 
terests.  Among  other  techniques,  type  systems  and  program  logics  have  been  widely  ap¬ 
plied  in  modern  programming  language  and  OS  researches.  One  representative  example 
is  the  Singularity  project  [33],  which  aims  to  build  a  highly  reliable  OS  using  a  type-safe 
programming  language  (C#)  and  other  techniques  for  program  specification  and  verifi- 
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cation.  Another  example  is  the  Verisoft  project  [23],  which  uses  computer-aided  logical 
proofs  to  obtain  assurance  of  the  correctness  of  critical  systems  including  OS  kernels.  Un¬ 
fortunately,  both  fall  short  at  the  code  for  context  switching  at  the  beginning  of  this  chap¬ 
ter:  Singularity  uses  unsafe  assembly  code  for  programming  context  switching;  Verisoft 
has  not  approached  below  the  level  of  user  processes  in  software  verification. 

The  lack  of  work  on  self-contained  verification  of  machine  level  context  and  thread 
implementation  reveals  subtle  limitations  of  traditional  methods.  For  example,  although 
type  systems  provide  excellent  support  for  modularity  and  higher-order  features,  they 
tend  to  be  very  specialized  when  dealing  with  low-level  system  code,  raising  both  flexi¬ 
bility  and  interoperability  issues.  As  another  example,  many  program  logics  suffer  from 
the  weak  support  on  higher-order  features  such  as  embedded  code  pointers  [53],  as  will 
be  discussed  in  details  in  this  dissertation. 

The  purpose  of  this  thesis  work  is  to  advance  the  research  of  machine  code  verification. 
In  particular,  we  want  to  achieve  a  better  balance  between  expressiveness  and  modularity 
over  existing  methods  for  low-level  system  and  application  code  verification.  Although 
theoretically  one  could  apply  any  verification  methods  on  machine  code,  expressiveness 
and  modularity  are  two  extremely  important  criteria  for  machine  code  verification. 

One  of  the  main  reasons  that  people  write  code  in  low-level  languages  instead  of  high- 
level  languages  is  the  expressiveness  of  the  low-level  languages  themselves.  The  speed, 
flexibility,  and  precise  control  of  machine  resources  are  examples  of  the  expressiveness 
of  machine  languages.  To  verify  such  kind  of  code,  the  expressiveness  of  the  verification 
system  has  to  be  much  more  powerful  than  those  used  for  high-level  languages. 

Separate  compilation  is  important  for  high-level  programs.  While  machine  code  does 
not  need  to  be  compiled,  in  many  cases  it  still  needs  to  be  linked  together  before  execution. 
Moreover,  separate  verification  is  even  more  important  for  machine  code  than  high-level 
programs,  since  machine  code  is  generally  larger  in  size  and  more  tedious  than  a  corre¬ 
sponding  high-level  program.  Its  verification  condition  and  process  are  also  generally 
much  larger  and  slower  than  the  high-level's.  For  a  machine  code  verification  system  to 
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be  practical  and  efficient,  it  must  have  as  good  support  of  modularity  as  the  high-level 
verification  systems. 

1.2  Previous  Work 

In  this  section,  we  discuss  existing  efforts  on  low-level  and  machine  code  verification. 

Typed  assembly  languages.  Type  system  has  been  popular  and  proved  successful  in 
programming  languages.  Thus,  a  natural  way  to  address  the  machine  and  assembly  level 
program  verification  is  to  design  a  type  system  for  assembly  language.  Partly  inspired 
by  the  Typed  Intermediate  Language  (TIL)  [57],  Type  Assembly  Language  (TAL)  [41]  is 
a  first  effort  to  address  the  low-level  code  safety  problem  in  the  traditional  type  system 
manner.  The  specification  of  TAL  is  written  in  syntactically  defined  types,  including  in¬ 
teger,  tuple,  code  pointer,  polymorphic,  and  existential  types.  Since  the  type  checking 
of  TAL  is  syntax  directed  and  decidable,  the  verification  process  is  fully  automatic.  By 
using  certifying  compilation  technology,  many  of  the  existing  high-level  programming 
languages  can  be  translated  into  TAL  code  with  type  annotation.  Later  improvement  of 
TAL  includes  stack  and  exception  [40],  modularity  and  dynamic  linking  [24],  dependent 
type  and  arrays  [60],  recursive  type  and  connections  with  foundational  proof-carrying 
code  [29],  heterogeneous  tuples  and  disjoint  sums  [13],  low-level  optimization  [11], 

However,  there  are  lot  safety  policies  which  have  not  been  supported  by  the  above 
work  on  TAL.  For  example,  memory  management  are  not  handle  in  any  of  them.  The  fact 
that  most  of  TAL  languages  require  a  hard-wired  "malloc"  or  "alloc"  instruction,  which 
is  generally  a  library  function  above  the  machine  instruction  level,  is  due  to  the  inability 
of  them  to  type  check  precise  memory  management.  To  support  these  safety  properties 
in  TAL,  one  would  need  to  incorporate  more  and  more  features  into  the  type  system  and 
the  interoperations  between  different  versions  of  TALs  may  also  be  problematic. 
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Proof-carrying  code.  Traditionally,  the  code  consumer  receives  binary  from  the  code 
producer  and  verify  the  code  before  executing  it.  To  shift  the  burden  of  verification  from 
code  consumer  to  code  producer,  Proof-Carrying  Code  (PCC)  [45,  43,  44,  12]  allows  a 
code  producer  to  provide  a  machine  (DEC  Alpha)  language  program  to  a  host  along  with 
a  formal  proof  of  its  safety.  The  specification  language  in  PCC  is  typing  predicates  with 
some  universal  logic  connectors  and  the  safety  policy  is  expressed  as  pre/ post  conditions 
of  code  sequences.  The  proofs  are  written  in  a  logic  extended  with  many  language-specific 
typing  rules.  By  using  verification-condition  generator  (VCgen),  both  the  code  producer 
and  the  code  consumer  can  automatically  calculate  the  safety  requirements  (lemmas)  at 
each  instruction  from  the  safety  policy.  For  those  simple  examples,  the  theorem  prover  can 
automatically  prove  those  lemmas.  Code  consumer  would  simply  use  a  proof  checker  to 
ensure  that  the  proofs  do  prove  those  lemmas.  By  proving  the  soundness  of  the  VCgen 
algorithm,  the  code  consumer  can  be  sure  that  the  safety  policy  has  been  satisfied.  Since 
the  source  language's  type  system  is  somehow  embedded  in  the  logic,  PCC  can  enjoy 
most  of  the  benefits  of  source  type  systems  such  as  modularity  and  support  more  general 
properties  through  logic  formulas. 

The  VCgen  and  proof  checker  are  inside  the  trusted  computing  base  and  are  error- 
prone  since  they  all  involve  language-specific  typing  rules  which  themselves  are  not  al¬ 
ways  error-free.  For  example,  [36]  discovered  a  serious  bug  in  the  typing  rules.  Another 
difficulty  of  PCC  is  that  language-specific  typing  rules  makes  interoperation  between  code 
written  in  different  languages  ad  hoc,  if  not  hard  at  all. 

Foundational  proof-carrying  code.  Foundational  Proof-Carrying  Code  (FPCC)  [6,  5] 
tackles  the  problems  of  PCC  by  constructing  and  verifying  its  proofs  using  strictly  the 
foundations  of  mathematical  logic,  with  no  type-specific  axioms.  The  machine  semantics 
of  Sun  Sparc  is  formalized  in  the  logic  in  the  first  place.  VCgen  can  now  be  removed  from 
trusted  computing  base.  Instead  of  directly  verifying  binaries  in  the  machine  level,  exit¬ 
ing  work  of  FPCC  all  takes  programs  written  in  a  slightly  higher-level  TAF-like  language 
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and  automatically  general  their  corresponding  FPCC  according  to  the  types  and  typing 
derivations.  In  the  case  of  semantic  approach  [6,  18,  3,  8]  types,  typing  derivations,  and 
soundness  proof  are  directly  interpreted  into  foundational  logic's  formula  and  proofs.  The 
syntactic  approach  [29]  simply  encodes  the  syntactic  type  system  in  the  logic  and  obtain 
the  FPCC  by  mapping  between  machine  and  FTAL  steps  and  utilizing  the  encoded  FTAL 
soundness  proof. 

Automated  proofs  of  object  code  for  a  widely  used  microprocessor.  Yu  [65]  uses  a 
limited  first-order  predicate  logic  (ACL)  to  define  and  specify  the  machine  (Motorola 
MC68020)  and  safety  policy  (Hoare-style  pre/ post-condition  relation  on  binary  encod¬ 
ing  of  machine  program  segment).  The  proof  of  the  safety  properties  is  done  by  manually 
specifying  lemmas  needed  and  their  usage,  and  letting  the  Boyer-Moore  Theorem  Prover 
(Nythm)  to  complete  the  whole  proof.  There  the  safety  properties  are  mostly  correctness 
of  functions,  including  those  in  a  unix  string  library. 

Cyclone  /  C-Cured  /  Vault.  Cyclone  [35],  CCured  [46],  and  Vault  [16]  are  safe  C-like  lan¬ 
guages  which  aim  at  providing  verification  support  at  a  level  close  to  assembly.  They 
could  serve  as  the  low-level  system  programming  language  connecting  with  machine 
code  verification  system  when  a  very  expressive  specification  language  is  not  required. 

JVML  /  MSIL.  Java  Virtual  Machine  Language  [27]  and  Microsoft  Intermediate  Lan¬ 
guage  [37]  are  intermediate-level  portable  languages  for  virtual  machines.  All  Java  and 
C#  programs  are  compiled  to  and  distributed  in  these  languages.  These  languages  can  be 
further  compiled  to  TAL-like  languages. 

1.3  Challenges  and  Contributions 

The  work  in  this  dissertation  lies  within  the  PCC  (and  FPCC)  framework.  In  principle, 
PCC  can  be  used  to  verify  safety  properties  of  arbitrary  machine-language  programs. 
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Existing  PCC  systems  [12,  29,  11,  13],  however,  have  focused  on  programs  written  in 
type-safe  languages  [26,  38]  or  variants  of  typed  assembly  languages  [41].  Type-based 
approaches  are  attractive  because  they  facilitate  automatic  generation  of  the  safety  proofs 
(by  using  certifying  compilers)  and  provide  great  support  to  modularity  and  higher-order 
language  features.  But  they  also  suffer  from  several  serious  limitations.  First,  types  are 
not  expressive  enough  to  specify  sophisticated  invariants  commonly  seen  in  the  verifica¬ 
tion  of  low-level  system  software.  Recent  works  on  logic-based  type  systems  [61, 55, 14, 1, 4] 
have  made  types  more  expressive  but  they  still  cannot  specify  advanced  state  invariants 
and  assertions  [54,  63,  64]  definable  in  a  general-purpose  predicate  logic  with  inductive 
definitions  [58].  Second,  type  systems  are  too  weak  to  prove  advanced  properties  and 
program  correctness,  especially  in  the  context  of  concurrent  assembly  code  [63,  20].  Fi¬ 
nally,  languages  of  different  style  often  require  different  type  systems,  making  it  hard  to 
reason  about  interoperability 

An  alternative  to  type-based  methods  is  to  use  Hoare  logic  [22,  31] — a  widely  applied 
technique  in  program  verification.  Hoare  logic  supports  formal  reasoning  using  very  ex¬ 
pressive  assertions  and  inference  rules  from  a  general-purpose  logic.  In  the  context  of 
foundational  proof-carrying  code  (FPCC)  [5,  63],  the  assertion  language  is  often  unified 
with  the  mechanized  meta  logic  (following  Gordon  [25]) — proofs  for  Hoare  logic  conse¬ 
quence  relation  and  Hoare-style  program  derivations  are  explicitly  written  out  in  a  proof 
assistant.  For  example.  Touchstone  PCC  [44]  used  Hoare-style  assertions  to  express  com¬ 
plex  program  invariants.  Appel  et  al  [6,  9]  used  Hoare-style  state  predicates  to  construct 
a  general  semantic  model  for  machine-level  programs.  Yu  et  al  [63,  64,  20]  recently  de¬ 
veloped  a  certified  assembly  programming  framework  that  uses  Hoare-style  reasoning  to 
verify  low-level  system  libraries  and  general  multi-threaded  assembly  programs. 

Unfortunately,  Hoare  logic,  as  Reynolds  [54]  observed,  does  not  support  higher-order 
features  such  as  embedded  code  pointers  (ECPs)  well.  Similarly,  features  such  as  im- 
predicative  polymorphisms,  recursive  specifications,  and  weak  update  references,  are  not 
handled  well  simultaneously  in  the  logical  setting.  How  to  modularly  support  these  fea- 
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tures  without  sacrificing  the  expressive  power  of  logic  is  the  first  and  major  challenge  we 
face  when  doing  machine  code  verification. 

The  second  challenge  we  face  when  doing  machine  code  verification  is  whether  the 
verification  method  is  applicable  to  real-world  program  verification  on  realistic  system 
kernel  code. 

The  third  challenge  is  whether  the  results  of  verification  is  an  isolated  one  or  can  actu¬ 
ally  connect  with  other  verification  systems  such  as  type  systems. 

The  contributions  of  this  dissertation  can  be  summarized  into  the  following  aspects, 
which  corresponds  to  the  structure  of  the  dissertation. 

Embedded  code  pointer  and  the  basic  XCAP  framework.  We  designed  the  XCAP  frame¬ 
work,  which  provides  the  first  simple  and  general  solution  to  the  ECP  problem  for  Hoare- 
logic  verification  systems.  By  "simple",  we  mean  that  our  method  does  not  alter  the  struc¬ 
ture  of  Hoare-style  program  derivations  and  assertions.  By  "general",  we  mean  that  our 
technique  can  indeed  handle  all  kinds  of  machine-level  ECPs,  including  those  hidden  in¬ 
side  higher-order  closures.  Relevant  details  can  be  found  in  Chapter  3. 

Impredicative  polymorphisms  and  recursive  specifications.  We  extended  the  XCAP 
framework  to  support  impredicative  polymorphisms  and  recursive  specifications.  Both 
extensions  cause  very  little  change  in  the  XCAP  inference  rules  and  meta  theory.  Thus, 
they  are  light  weight  and  proved  sound.  Using  the  extended  XCAP,  we  solve  the  ECP 
problem  for  separation  logic  [54]  and  present  a  verification  of  a  destructive  list-append 
function,  which  is  listed  as  an  example  in  [54],  Relevant  details  can  be  found  in  Chapter  4. 

Weak  update  and  a  translation  from  typed  assembly  language.  Weak  update,  also 
termed  as  "general  reference",  is  another  higher-order  feature  that  logic-based  verifica¬ 
tion  methods  fail  to  support  well.  We  once  again  extended  the  XCAP  framework  to  sup¬ 
port  weak  update,  using  similar  syntactic  technique  for  the  support  of  ECP  in  Chapter  3. 
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We  then  explore  the  relationship  between  XCAP  and  typed  assembly  languages  (TAL). 
TAL  and  XCAP  are  suitable  for  different  kinds  of  verification  tasks.  Previously,  programs 
verified  in  either  one  of  them  can  not  interoperate  freely  with  the  other,  making  it  hard 
to  integrate  them  into  a  complete  system.  Moreover,  the  relationship  between  TAL  and 
CAP /XCAP  lines  of  work  has  not  been  discussed  extensively. 

We  compare  the  type-based  and  logic-based  methods  by  presenting  a  type-preserving 
translation  from  a  TAL  language  to  XCAP.  The  translation  involves  an  intermediate  step  of 
a  "semantic"  TAL  language.  Our  translation  supports  polymorphic  code,  mutable  refer¬ 
ence,  existential,  and  recursive  types.  Since  we  proved  typing  preservation  for  the  transla¬ 
tion  from  TAL  to  XCAP,  there  is  a  clear  path  to  link  and  interoperate  well-typed  programs 
from  traditional  certifying  compilers  with  certified  libraries  by  XCAP.  Relevent  details  can 
be  found  in  Chapter  5. 

A  port  of  XCAP  to  the  x86  architecture.  We  port  XCAP  to  a  faithful  subset  of  the  x86 
architecture,  which  adds  the  support  of  instruction  decoding,  finite  machine  word,  word- 
aligned  byte-addressed  memory,  conditional  flags,  built-in  stack  and  push/ pop  instruc¬ 
tions,  and  function  call/ return  instructions.  On  top  of  it,  we  made  practical  adaptations 
and  built  useful  abstractions,  particularly  on  the  handling  of  the  stack  and  function  calls. 
We  demonstrate  its  usage  and  these  abstractions  for  the  verification  of  a  polymorphic 
queue  module.  Relevent  details  can  be  found  in  Chapter  6. 

A  certified  mini  thread  library.  We  mechanically  verified  a  thread  implementation  at 
the  machine  level  using  the  ported  XCAP.  Using  the  first  mechanized  proof  for  the  safety 
of  a  machine-level  thread  implementation,  we  demonstrate  the  power  and  practicality  of 
the  XCAP  framework,  and  thus  the  fact  that  the  certification  of  complex  machine-level 
system  code  is  not  beyond  reach.  The  specifications  and  proof  of  MTH  modules  and  rou¬ 
tines  are  modular.  Each  piece  of  the  code  is  specified  and  proved  with  minimal  reference 
to  external  code.  For  example,  in  the  verification  of  context  module,  there  is  no  mention 
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of  thread  at  all.  More  details  can  be  found  in  Chapter  7. 


Mechanization.  One  key  feature  of  the  XCAP  framework  is  mechanization.  Not  only 
did  we  mechanize  our  machine  syntax,  machine  semantics,  assertion  languages,  interpre¬ 
tations,  inference  rules,  and  program  specifications  and  proofs  in  a  general  mathematic 
logic,  we  also  mechanized  the  complete  meta  theory  of  XCAP.  Plus,  we  want  to  directly 
obtain  the  power  of  higher-order  predicate  logic,  through  a  shallow  embedding.  For  these 
reasons,  our  usage  of  the  Coq  proof  assistant  [58]  is  to  treat  it  as  both  a  mechanized  logic 
framework  and  a  mechanized  meta  logic  framework.  More  details  can  be  found  in  Chap¬ 
ter  8. 


10 


Chapter  2 


Background 


Most  of  the  theoretical  presentations  and  discussions  in  this  dissertation  are  based  on  a 
same  RISC-like  ideal  target  machine  (TM).  Most  of  the  verification  systems  and  proofs  in 
this  dissertation  assume  a  same  underlying  formal  meta  logic — a  variant  of  the  Calculus 
of  Inductive  Constructions  (CiC)  [50],  upon  which  the  Coq  proof  assistant  is  based.  For 
proof  mechanization  purpose,  we  refer  to  it  as  our  "mechanized  meta  logic".  Certified 
Assembly  Programming  (CAP)  is  the  logic-based  machine  code  verification  framework 
from  which  the  work  in  this  dissertation  evolves.  In  this  chapter,  we  prepare  the  reader 
with  the  machine,  the  logic,  and  the  baseline  CAP. 

2.1  The  Target  Machine 

All  theoretical  results  presented  in  this  dissertation  share  a  common  raw  target  machine 
TM,  as  defined  in  Figure  2.1.  A  TM  program  (P),  an  entire  machine  configuration,  consists 
of  a  code  heap  (C),  a  dynamic  state  component  (S)  made  up  of  a  register  file  (M)  and  a  data 
heap  (H),  and  an  instruction  sequence  (I)  to  be  executed  next.  Code  heap  is  a  collection 
of  code  labels  (f )  and  the  code  sequence  they  points  to.  The  register  file  is  made  up  of  32 
registers,  while  the  data  heap  is  a  partial  mapping  from  data  labels  (1)  to  machine  words 
(w).  In  essence,  f ,  1,  and  w  are  all  just  plain  natural  numbers  (/).  Since  TM  has  an  infinite 
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(Program) 

P 

(CodeHeap) 

C 

(State) 

§ 

(Mem) 

H 

(Regfile) 

R 

(Reg) 

r 

(Word, Labels) 

w,f,l 

( InstrSeq ) 

I 

(Instr) 

c 

(C,s,l) 

(M,R) 

{l w}* 

{r  w}* 

{rt}t€{0...31} 

i  ( nat  nums ) 
c;I  |  jd  f  |  jmp  r 

add  rd,rsrt  |  addi  rj.  rv. i  |  alloc  rd,i  |  bgti  rs,i,± 
free  r s,i  |  Id  rd,r s(i)  |  mov  rd,rs  |  movi  r d,i  |  st  rf/(z'),rs 


Figure  2.1:  Syntax  of  target  machine 

word  size,  we  expects  its  data  heap  to  be  bounded  but  infinite — there  is  no  upper  limit  on 
how  large  a  data  heap  can  be,  but  at  any  program  execution  point,  all  the  allocated  heap 
cells  are  below  a  certain  boundary  (this  is  because  in  TM  one  can  only  allocate  a  finite 
amount  of  memory  in  each  allocation). 

TM  follows  the  RISC  style  for  simplicity  Its  instruction  set  of  TM  is  minimal  but  exten¬ 
sions  are  straightforward.  There  are  instructions  (c)  for  arithmetic  operations  (add  rd,rsrt, 
addi  r,/,r s,i),  data  movements  (mov  rd . rv  and  movi  r d,i),  memory  allocation/deallocation 
(alloc  r d,i  and  free  rv.  /),  memory  accesses  (Id  rd,rs(i)  and  st  r,/(/).rs),  and  condition  jumps 
(bgti  rs,i,f).  Each  code  block  (instruction  sequence)  must  end  with  either  a  direct  jump 
(jd  f )  or  an  indirect  jump  (jmp  r). 

The  operational  semantics  of  this  language  (see  Figure  2.2)  should  pose  no  surprise. 
The  add  instructions  add  values  from  source  registers  and  immediate  values  and  put 
the  sums  into  the  destination  registers.  The  data  movement  instructions  take  either  the 
source  register  value  or  an  immediate  value,  and  put  it  into  the  destination  register.  Heap 
allocation  instruction  takes  a  required  size  i  and  allocates  a  continuous  memory  block  of 
that  size,  with  its  initial  value  undefined  (so  for  safe  execution  of  programs,  these  values 
should  not  be  used).  To  dispose  a  piece  of  memory,  every  cell  in  it  must  be  previously 
allocated.  Similarly,  to  access  a  memory  cell,  it  must  be  previously  allocated.  Whether 
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if  1  = 

then  (C,  i — > 

jdf 

(C,  (H,R),C(f))  when  f  Gdom(C) 

jmp  r 

(C,  (H,R),C(R(r)))  when  R(r)  Edom(C) 

bgti  rs,;\f;F 

(C,  (H,  R) ,  F)  when  R(ri)  <  i ; 

(C,  (H,R),C(f))  when  R(rv)  > i 

c;F 

(C,Nextc(BI,R),F) 

where 


if  c  = 

then  Nextc(BI,R)  = 

add  rd,rsrt 

(H,R{rf/'^>R(rs.)+R(rf)}) 

addi  rd,rs,i 

(H,R{rf/'^R(rs.)+/}) 

mov  rdlrs 

(H,R{rf/'^R(r,)}) 

movi  rd,i 

(H,R{rf/'^/}) 

alloc  r d,i 

(BI{1~>  1+/- W_})K{rd'N^1}) 

where  1, . . . ,  1+i—  1  ^  dom(BI)  and   is  a  random  value 

free  r s,i 

(H/{R(rs), . . .  ,R(r,)+i-l},R) 
when  R(rs), . . .  ,R(rs)+/— 1  G  dom(H) 

Id  rd,rs(i) 

(H,R{r^~>H(R(rj)+i)})  when  R(ri)+/  E  dom(BI) 

st  rd(i),rs 

(H{R(r,/)+/'^R(rs)},R)  when  R(r^)+i  E  dom(BI) 

Figure  2.2:  Operational  semantics  of  target  machine 


directly  jumping  to  an  immediate  code  label  or  a  register  value,  the  target  address  must 
point  to  a  piece  of  code  in  the  code  heap.  Branch  instruction  compares  the  register  value 
with  an  immediate  value,  and  decides  if  it  should  continue  with  the  next  instruction  or 
jump  to  somewhere  else.  In  all  the  above  cases,  when  the  side-conditions  of  instructions 
are  unsatisfied,  the  execution  of  TM  gets  "stuck."  To  guarantee  that  a  TM  program  will 
never  enter  the  "stuck"  status  is  the  minimum  requirement  for  any  verification  systems. 


2.2  Mechanized  Meta  Logic 


Both  the  syntax  and  the  operational  semantics  of  TM,  as  well  as  all  the  verifications  sys¬ 
tems,  program  specifications,  and  proofs  in  this  dissertation,  are  defined  upon  a  formal 
meta  logic.  In  this  dissertation  we  use  a  variant  of  the  calculus  of  inductive  constructions 
(CiC)  [50],  which  is  a  higher-order  predicate  logic  extended  with  powerful  inductive  def- 
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(Term)  A,B  ::=  Set  \  Prop  \  Type  \  x  \  far.A.B  \AB\A  —>B  |  FLr  :A.B  |  inductive  definitions 
(Prop)  p,q  ::=  True  |  False  \  ~^p  \  p  Aq  \  p\/ q  \  p  D  q  \  Vx:A. p  \  3x:A.p  \  . . . 

Figure  2.3:  Mechanized  meta  logic 

initions.  We  informally  present  our  formal  meta  logic  in  Figure  2.3.  Terms  in  CiC  can 
be  sorts  (Set,  Prop,  and  Type),  variables,  function  abstractions,  function  applications,  non¬ 
dependent  products,  dependent  products,  or  inductive  definitions.  We  omit  the  details 
of  inductive  definitions  and  will  instead  use  examples  to  explain  them  later.  The  logic 
part  of  CiC  contains  terms  of  Prop  sort,  which  provides  common  logic  quantifiers  and 
connectives,  and  allows  user  expansions  by  inductively  defined  propositions. 

Since  one  goal  of  the  work  in  this  dissertation  is  to  generate  machine-checkable  proofs, 
we  want  our  formal  meta  logic  to  be  a  mechanized  one.  We  select  CiC  based  on  the  fact 
that  it  is  the  underlying  logic  theory  for  the  Coq  proof  assistant  [58].  We  use  Coq  for 
two  purposes.  The  first  is  to  use  it  as  a  mechanized  meta  logic  framework,  in  which 
we  can  represent  all  the  syntax,  rules,  and  meta  theory  of  our  machine  and  verification 
systems  in  the  Set  and  Type  sort  of  Coq.  For  example,  to  represent  TM,  machine  state  can 
be  embedded  as  a  State  type  (which  has  Set  sort  in  Coq);  registers,  machine  instruction 
sequences,  commands,  and  execution  semantics  can  be  defined  as  inductive  definitions. 


14 


Inductive  Register  :  Set  :=  rO  I  rl  I  ...  I  r31. 


Inductive  Command 


Set 


add  :  Register  ->  Register  ->  Register  ->  Command 
addi  :  Register  ->  Register  ->  Word  ->  Command 
mov  :  Register  ->  Register  ->  Command 


Inductive  InstrSeq 


Set  :=  iseq 

I  jd 

I  jmp 


Command  ->  InstrSeq  ->  InstrSeq 
Word  ->  InstrSeq 
Register  ->  InstrSeq 


Inductive  Next  :  Command  ->  State  ->  State  ->  Prop  := 

I  stp_add  :  forall  rd  rs  rt  HR, 

Next  (add  rd  rs  rt)  (H,  R)  (H,  uR  R  rd  (R  rs  +  R  rt)) 
I  stp_mov  :  forall  rd  rs  H  R, 

Next  (mov  rd  rs)  (H,  R)  (H,  uR  R  rd  (R  rs)) 

I  stp_ld  :  forall  rd  rs  w  H  R  w’ , 

lookup  H  (R  rs  +  w)  w’  -> 

Next  (Id  rd  rs  w)  (H,  R)  (H,  uR  R  rd  w’) 


Inductive  STEP  :  Program  ->  Program  ->  Prop  := 

I  stp_iseq  :  forall  CSS’  cl, 

Next  c  S  S’  -> 

STEP  (C,  (S,  iseq  c  I))  (C,  (S’,  I)) 
I  stp_jd  :  forall  C  S  1  I, 

lookup  C  1  I  -> 

STEP  (C,  (S,  jd  1))  (C,  (S,  I)) 

I  stp_jmp  :  forall  C  S  r  I, 

lookup  C  (_R  Sr)  I  -> 

STEP  (C,  (S,  jmp  r))  (C,  (S,  I)) 


General  safety  policies  can  then  be  defined  as  meta  logic  predicates  over  the  entire 
machine  configuration;  they  will  have  the  Program  — >  Prop  type.  For  example,  the  simple 
"non-stuckness"  safety  policy  for  TM  can  be  defined  as  follows: 

AJP.  'in : Nat .  3P7 :  Program.  P  i — >n  P7. 

Here  i — >n  is  the  composition  of  — >"  for  n  times.  Under  this  setting,  if  SafeQ  denotes  a 
particular  customized  safety  policy,  a  certified  binary  is  just  a  pair  of  program  P  together 
with  a  proof  object  of  type  Safe( P),  all  represented  in  the  mechanized  meta  logic. 

The  second  usage  of  CiC/  Coq  is  to  directly  use  its  build-in  higher-order  predicate  logic 
(Prop)  to  serve  as  (part  of)  the  assertion  logics,  which  are  used  to  write  program  specifi- 
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cations.  Thus  there  is  no  need  to  define  a  complete  new  general  logic  and  its  meta  theory, 
which  makes  the  approaches  in  this  paper  lightweight.  In  other  word,  we  use  shallow 
embedding  instead  of  deep  embedding  for  the  higher-order  predicate  logic  part  of  the  as¬ 
sertion  languages  in  this  dissertation.  Actually,  right  in  the  next  section,  we  will  see  how 
the  original  CAP  utilizes  this  technology  and  becomes  an  extremely  simple  framework. 

It  is  important  to  note  that,  although  the  theory  and  implementation  in  this  disserta¬ 
tion  are  presented  and  done  with  CiC/Coq,  we  believe  that  the  key  ideas  from  our  results 
are  applicable  to  other  mechanized  meta  logics. 


2.3  The  Certified  Assembly  Programming  Framework 

As  suggested  by  its  name,  certified  assembly  programming,  CAP  [63]  is  a  logic-based 
verification  framework  for  machine  code  verification.  In  essence,  CAP  is  a  Hoare-logic 
framework  for  reasoning  about  assembly  programs.  Note  that  the  CAP  framework  pre¬ 
sented  in  this  section  is  slightly  different  from  the  original  one,  as  we  want  to  let  it  share 
a  very  similar  structure  with  the  work  in  this  dissertation. 

Traditionally,  Hoare-logic  systems  usually  use  the  following  judgment  to  reason  about 
program  safety  and  correctness. 

{ precondition }  statement  {postcondition} 

Where  pre-  and  post-conditions  are  written  in  certain  assertion  logic,  and  describe  the 
state  before  and  after  the  execution  of  statement. 

In  this  dissertation,  however,  TM  programs  are  often  written  in  continuation-passing 
style  [7],  as  there  are  no  instructions  directly  in  correspondence  with  function  call  and  re¬ 
turn  in  a  high-level  language.  Hence  post-conditions  in  Hoare  logic  do  not  have  explicit 
counterparts  in  CAP;  they  are  often  interpreted  as  preconditions  of  the  return  continua¬ 
tions.  The  basic  form  of  judgment  in  CAP  is 

{a}  I 
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(CdHpSpec) 

¥ 

{f^a}* 

(. Assertion ) 

a 

e 

State  — >  Prop 

( Assert  Imp ) 

a=>  a7 

_A 

VS.  a  S  D  a7  S 

(, Steplmp ) 

a  a7 

_A 

VS.  a  S  D  a7  Nextc  (S) 

Figure  2.4:  Assertion  language  of  CAP 

where  I  is  the  code  block  to  be  reasoned  about,  and  a  is  an  assertion  describing  the  expec¬ 
tation  on  machine  states  before  executing  I. 

Assertion  language.  Following  Gordon  [25],  CAP's  assertion  language,  as  presented  in 
Figure  2.4,  is  directly  unified  with  the  underlying  mechanized  meta  logic  ( i.e .,  shallow 
embedding).  CAP  assertions  (a)  tracks  the  state  component  in  the  machine  configuration, 
so  any  terms  of  type  States  Prop  are  valid  CAP  assertions.  For  example,  an  assertion 
specifying  that  the  registers  ri  and  r2  store  a  same  value  and  the  register  1-3  contains  a 
non-NULL  value  can  be  written  as: 

L(HI,M).M(ri)  =M(r2)  AM(r3)^NULL. 

To  simplify  the  presentation,  we  lift  propositional  implication  (d)  to  assertion  level  (=£■). 

In  Figure  2.4,  there  is  a  construct  named  code  heap  specification  (lP)  for  expressing 
user-defined  safety  requirements  on  program.  A  code  heap  specification  associates  every 
code  label  with  an  assertion,  with  the  intention  that  the  pre-condition  of  a  code  block  is 
described  by  the  corresponding  assertion. 

Inference  rules.  CAP  defines  a  set  of  inference  rules  for  proving  judgments  for  well- 
formed  programs,  code  heaps,  and  instruction  sequences  (see  Figure  2.5). 

Top-down,  a  TM  program  is  well-formed  (rule  PROG)  under  assertion  a  if  both  the 
global  code  heap  and  the  current  instruction  sequence  are  well-formed  and  the  machine 
state  satisfies  assertion  a. 

To  support  separate  verification  of  code  modules,  we  have  made  some  changes  to 
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'Pg  F  {a}  P  ( Well-formed  Program ) 


*yGhC:*yG  (aS)  ych{a}I 

^Gh{a}(C,S,I) 


(PROG) 


^/JvhC:^ 


(Well-formed  Code  Heap) 

^h{a,}I;-  Vff 


(CDHP) 


^2hC2:^2  ^wl(f)='Pw2(f) 

dom(Ci)ndom(C2)  =  0  Vf  edom(vFJA,1)ndom(vF;iV2) 
^/iVlU^;Jv2hCiUC2:^iU^2 


(LINK) 


Ph{a}I  ( Well-formed  Instruction  Sequence ) 


a  =^c  a7  xFF{a/}I  ce{add,addi,mov,movi, alloc, free, Id, st} 


^h{a}c;I 

a^'F(f)  f  €dom(\P) 
^b{a}jdf 


(SEQ) 


(JD) 


(X(H,M).M(r ,.)</  A  a  (H,R))  =>  a'  Ph{a'}I 
(X(H,M).M(rs)>z  A  a(H,M))  =*  ¥(f )  fEdom('P) 

'Fbja}  bgti  r,,z,f;I 

a  =►  (A,(H,M). a'(H,M)  A  R(r)edomOF)  A  xF(M(r))  =  a/ 


'F  F  {a}jmp  r 


(BGTI) 

(jMP ) 


Figure  2.5:  Inference  rules  of  CAP 
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the  inference  rules  for  well-formed  code  heaps  from  the  original  CAP.  A  module  is  de¬ 
fined  as  a  small  code  heap  which  can  contain  as  few  as  one  code  block.  Each  module  is 
associated  with  an  "import"  *PW  interface  and  an  "export"  interface  VF.  A  programmer 
first  establishes  well-formedness  of  each  individual  module  via  the  CDHP  rule.  Two 
non-conflicting  modules  can  then  be  linked  together  via  the  link  rule.  All  code  blocks 
will  eventually  be  linked  together  to  form  a  single  global  code  heap  with  specification 
'Eg  (which  is  used  in  the  well-formed  program  rule).  These  two  code  heap  rules  provide 
basic  support  for  modular  verification.  However,  as  we  will  show  in  the  next  Chapter, 
modularity  breaks  down  when  we  reason  about  first-class  code  pointers  passing  across 
the  module's  boundary. 

The  intuition  behind  well-formed  instruction  sequence  judgment  is  that  if  the  instruc¬ 
tion  sequence  I  starts  execution  in  a  machine  state  which  satisfies  assertion  a,  then  ex¬ 
ecuting  I  is  safe  with  respect  to  the  specification  VP.  An  instruction  sequence  preceded 
by  c  is  safe  (rule  SEQ)  if  we  can  find  another  assertion  a'  which  serves  both  as  the  post¬ 
condition  of  c,  (that  is,  a'  holds  on  the  updated  machine  state  after  executing  c),  and  as 
the  precondition  of  the  tail  instruction  sequence. 

A  direct  jump  is  safe  (rule  JD)  if  the  current  assertion  can  imply  the  precondition  of 
the  target  code  block  as  specified  in  VP.  An  indirect  jump  is  similar  (rule  JMP)  except  that  it 
refers  to  the  register  file  for  the  target  code  label;  unfortunately,  this  treatment  of  first  class 
code  pointers  requires  reasoning  about  global  control  flow  and  breaks  the  modularity  (see 
the  next  chapter). 

A  programmer's  task,  when  proving  the  well-formedness  of  a  code  block,  involves 
mostly  applying  the  appropriate  inference  rules,  finding  intermediate  assertions  like  a', 
and  proving  all  the  assertion  subsumption  relations  (which  are  implemented  as  logical 
implications  in  the  mechanized  meta  logic). 

Soundness.  The  soundness  theorem  below  guarantees  that  given  a  well-formed  CAP 
program,  starting  with  its  current  instruction  sequence,  the  machine  will  never  get  stuck. 
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Theorem  2.1  (CAP  Soundness) 

If  vPf;  b  {a} P,  then  for  all  natural  number  n,  there  exists  a  program  P7  such  that  P  i — >"  P7. 

The  proof  for  this  theorem  can  be  established  following  the  syntactic  approach  of  prov¬ 
ing  type  soundness  [59]  by  proving  the  progress  and  preservation  lemmas. 

Lemma  2.2  (CAP  Progress) 

If  'Pg  b  {a} P,  then  there  exists  a  program  P7  such  that  P  i — >  P7. 

Lemma  2.3  (CAP  Preservation) 

If  'Pg  b  {a}  P  and  P  i — >  P7  then  there  exists  an  assertion  a7  such  that  VF(;  b  {a7}  P7. 

In  order  to  address  the  new  link  rule,  we  need  the  following  code  heap  typing 
lemma,  whose  proof  needs  the  instruction  sequence  weakening  lemma  below. 

Lemma  2.4  (CAP  Code  Heap  Typing) 

If 'Pw  b  C:*P  and  f  edom(*P),  then  f  edom(C)  and  'P^  b{'P(f)}C(f ). 

Lemma  2.5  (CAP  Instruction  Sequence  Weakening) 

If 'P  b{a}I,  'PC'P7,  and  a7  =>- a  then  'P7  b  {a7} I. 

Yu  et  al  [63,  64]  have  also  shown  that  CAP  can  be  easily  extended  to  prove  more  gen¬ 
eral  safety  properties  by  introducing  invariant  assertions  into  the  inference  rules.  Further¬ 
more,  by  mechanizing  the  CAP  inference  rules  and  the  soundness  proofs  in  Coq,  we  can 
easily  construct  FPCC  packages  for  CAP  programs  [63,  28]. 

There  have  been  many  works  following  the  CAP  framework:  dynamic  storage  allo¬ 
cation  [63],  interfacing  with  TAL  [28],  concurrent  verification  [64,  20],  support  of  embed¬ 
ded  code  pointers  [47]  (to  be  discussed  in  this  dissertation),  stack-based  control  abstrac¬ 
tion  [21],  and  open  framework  for  interoperation  [19]. 
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Chapter  3 


Embedded  Code  Pointers  and  the 
Basic  XCAP  Framework 


In  this  chapter  we  present  an  important  problem  with  CAP  and  other  logic-based  verifica¬ 
tion  methods:  embedded  code  pointers  (ECP).  Being  a  crucial  concept  for  programming, 
the  lack  of  modular  and  expressive  ECP  support  prevents  these  methods  from  being  used 
to  certify  realistic  system  kernel  code.  We  then  present  our  solution  for  the  ECP  prob¬ 
lem,  a  new  XCAP  framework  evolved  from  CAP.  We  first  discuss  the  idea  of  "extended 
propositions,"  which  can  be  roughly  viewed  as  a  mixture  of  logic  formulas  and  syntactic 
constructs.  We  then  discuss  the  basic  structure  of  the  new  XCAP  framework  and  show 
how  to  use  syntactic  techniques  to  perform  modular  reasoning  on  ECPs  while  still  retain¬ 
ing  the  expressive  power  of  Hoare  logic.  XCAP  shares  the  same  target  machine  TM  (see 
Figure  2.1  and  2.2)  with  CAP. 

XCAP  provides  the  first  simple  and  general  solution  to  the  ECP  problem  for  Hoare- 
logic  verification  systems.  Here,  by  "simple,"  we  mean  that  our  method  does  not  alter  the 
structure  of  Hoare-style  program  derivations  and  assertions.  By  "general",  we  mean  that 
our  technique  can  truly  handle  all  kinds  of  machine-level  ECPs,  including  those  hidden 
inside  higher-order  closures  (together  with  next  chapter). 
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3.1  Embedded  Code  Pointers 


ECPs,  based  on  context  and  time,  are  often  referred  to  as  computed-gotos,  stored  proce¬ 
dures,  higher-order  functions,  indirect  jumps,  continuation  pointers,  and  so  on.  As  the 
variations  of  its  name  suggest,  ECP  has  long  been  an  extensively  used  concept  in  pro¬ 
gramming.  Because  of  the  ECP  problem,  PCC  systems  based  on  Hoare  logic  have  to 
either  avoid  supporting  indirect  jumps  [44,  64],  limit  the  assertions  (for  ECPs)  to  types 
only  [28],  sacrifice  the  modularity  by  requiring  whole-program  reasoning  [63],  or  resort 
to  construction  of  complex  semantic  models  [9,  2],  In  Reynolds  [54],  supporting  ECPs  is 
listed  as  one  of  the  main  open  problems  for  separation  logic. 

At  the  assembly  level  (as  in  TM),  ECPs  denote  those  memory  addresses  (labels)  stored 
in  registers  or  memory  cells,  pointing  to  the  start  of  code  blocks.  A  special  kind  of  ECPs  is 
the  function  return  addresses;  more  general  kinds  of  ECPs  can  also  be  found  in  closures. 
Supporting  ECPs  is  an  essential  part  of  assembly  code  verification.  To  understand  better 
the  ECP  problem,  let's  take  a  look  at  the  following  example: 

fl:  mov  rl,  fl  //no  assumption 
jd  f  2 

f2:  jmp  rl  //  rl  stores  an  ECP  with  no  assumption 

Here  we  have  defined  two  assembly  code  blocks.  The  first  block,  labeled  f  i ,  makes  no 
assumption  about  the  state;  it  simply  moves  the  code  label  f  i  into  register  ri  and  then 
directly  jumps  to  the  other  code  block  labeled  f  i_-  The  f  2  block  requires  that  upon  entering, 
register  r\  must  contain  a  code  pointer  that  has  no  assumption  about  the  state;  it  simply 
makes  an  indirect  jump  to  this  embedded  code  pointer  and  continues  execution  from 
there.  If  the  execution  initially  starts  from  f  1,  the  machine  will  loop  forever  between  the 
two  code  blocks  and  never  get  stuck.  It  is  important  to  note  that  both  code  blocks  are 
independently  written  so  they  are  expected  to  not  only  just  work  with  each  other,  but 
with  any  other  code  satisfying  their  specifications  as  well. 

We  introduce  a  predicate,  cptr(f,a),  to  state  that  value  f  is  a  valid  code  pointer  with 
precondition  a.  Following  the  notations  in  Section  2.3,  we  define  the  "no  assumption" 
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assertion  as 


ar  =  XS.True. 

The  preconditions  for  f  i  and  f  2  can  be  written  as 

A 

aj  =  ar 


and 


a2  =  X(H,M).ar  (H,M)  A  cptr(R(ri),ar). 
But  what  should  be  the  definition  of  cptr(f ,  a)? 


Semantic  approach.  The  semantic  approach  to  this  problem  is  to  directly  internalize  the 
Hoare  derivations  as  part  of  the  assertion  language  and  to  define  cptr(f ,  a)  as  valid  if  there 
exists  a  Hoare  derivation  for  the  code  block  at  f  with  precondition  a.  Using  the  notation 
from  CAP,  it  can  be  informally  written  as: 

cptr(f,a)  A  xf/t-{a}C(f). 

This  is  clearly  ill-formed  since  T  is  not  defined  anywhere  and  it  can  not  be  treated  as  a 
parameter  of  the  cptr  predicate — the  assertion  a,  which  is  used  to  form  T,  may  refer  to  the 
cptr  predicate  again. 

Semantic  approach:  stratification.  To  break  the  circularity,  one  approach  [49,  42]  is  to 
internalize  Hoare-logic  derivations  as  part  of  the  assertion  language  and  stratify  all  ECPs 
(as  well  as  the  code  heaps  and  specifications  that  contain  them)  so  that  only  the  cptr  def¬ 
initions  (and  well-formedness  proofs)  for  highly-ranked  code  blocks  can  refer  to  those  of 
lower-ranked  ones.  More  specifically,  a  first  order  code  pointer  does  not  specify  any  ECP 
in  its  precondition  (its  code  does  not  make  any  indirect  jump)  so  we  can  define  cptr  over 
them  first;  an  n- th  order  code  pointer  can  only  refer  to  those  lower-order  ECPs  so  we  can 
define  cptr  inductively  following  the  same  order.  The  cptr  predicate  definition  becomes: 
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cptr(f,a,fc)  =  TVi  h{a}Cjfc_i(f). 


While  the  typing  structures  of  well-formed  instruction  sequences  would  look  like  below. 


'ho  b {a()}  . . . ;jd  ... 


'h«-i  b{a„_!}  . . .  ;jmp  ... 

'h,,  b{a„}  . . . ;jmp  ... 

Stratification  works  for  monomorphic  languages  with  simple  procedure  parameters  [49, 
42],  however,  for  machine-level  programs  where  ECPs  can  appear  in  any  part  of  the  mem¬ 
ory,  tracking  the  orders  of  ECPs  is  impossible:  ECPs  can  appear  on  the  stack  or  in  another 
function's  closure  (often  hidden  because  closures  are  usually  existentially  quantified  [39]). 

Semantic  approach:  indexing.  Another  approach,  by  Appel  et  al  [9,  2,  56],  also  intro¬ 
duces  an  parameter  k  to  the  cptr  predicate.  Instead  of  letting  k  refer  to  the  depth  of  nesting 
ECPs  as  the  stratification  approach  does,  the  "index"  k  now  refers  to  the  maximum  num¬ 
ber  of  safe  future  computation  steps.  Roughly  speaking,  cptr(f ,  a,&)  means  that  it  is  "safe" 
to  execute  the  next  (at  most)  k— 1  instructions,  starting  from  the  code  block  at  f  with  pre¬ 
condition  a. 

cptr(f,a,k)  =  V/<k.vP  h,-  (a}C(l) 

Note  that  here  a  and  XP  are  not  defined  as  state  predicates  and  mapping  from  code  labels 
to  them.  Instead,  indexing  must  also  be  done  for  assertions  and  all  the  Hoare  inference 

rules.  For  example,  the  indirect  jump  rule  would  have  the  following  shape: 

a  =>-  X(HI,R).  a'  (H,M)  Acptr(M(r),  a',&— 1) 
xPbt{a}jmpr 

Indexed  assertions  can  only  describe  safety  properties  of  finite  steps.  To  establish 
safety  properties  about  infinite  future  executions,  one  needs  to  do  induction  over  the  in¬ 
dex.  Because  of  the  pervasive  uses  of  indices  everywhere,  indexing  dramatically  alters 
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the  structure  of  Hoare-logic  program  derivations  and  assertions.  This  makes  it  hard  to 
use  together  with  other  extensions  such  as  separation  logic  [54]  and  rely-guarantee-based 
reasoning  [64,  20]. 

Syntactic  approach.  Rather  than  using  the  semantic  methods,  CAP  takes  a  syntactic  ap¬ 
proach  and  is  essentially  reasoning  about  the  control  flow.  Validity  of  ECPs  is  established 
in  two  steps.  In  the  first  step,  in  indirect  jump  rule  JMP  it  only  requires  that  we  look  up 
the  assertion  for  the  target  code  label  stored  in  register  r  from  the  code  heap  specification 
'P.  (The  equality  of  assertions  used  here  is  the  Coq  equality  eq  which  is  equivalent  to  the 
Leibniz'  equality.) 

a=>  (A,(H,R).a'  (H,R)  A  M(r)Gdom(»P)  A  T/(M(r))  =  a/) 
vFh{a}jmpr 

Then  in  the  top-level  PROG  rule  the  well-formedness  of  global  code  heap  is  checked 
0rG  b  C:'PG)  to  make  sure  that  every  assertion  stored  in  vTf;  (which  is  the  union  of  all 
local  VF)  is  indeed  a  valid  precondition  for  the  corresponding  code  block.  The  effect  of 
these  two  steps,  combined  together,  guarantees  that  the  Hoare  derivations  internalized  in 
the  semantic  approach  is  still  obtainable  in  the  syntactic  approach  for  the  preservation  of 
the  whole  program.  This  approach  is  often  used  by  type  systems  such  as  TAL. 

But  how  do  we  know  that  such  label  indeed  falls  into  the  domain  of  VT?  We  reason 
about  the  control  flow.  Take  the  code  block  of  f  2  for  example,  we  need  to  prove: 

a2  =>  (A,(H,R).a'  (H,R)  A  R(n)  Edom('P)  A  'P(R(r1))  =  a') 
which  unfolds  into 

VH,M.(ar  (H,K)  A  cptr(K(ri),ar))  D  (a'  (H,R)  A  R(n)  Gdom(T')  A  'F(R(ri))  =  a7). 
Clearly  we  should  require  the  following  to  hold: 

VH,M.cptr(M(r1),ar)  D  (R(n)Gdom('P)  A  »P(M(r1))  =  a7). 
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If  we  let  the  cptr  predicate  directly  refer  to  'F  in  its  definition,  assertion  and  specification 
become  cyclic  definitions  since  VF  consists  of  a  mapping  from  code  labels  to  assertions 
(which  can  contain  cptr). 

Previous  CAP  implementation  [63]  transforms  the  above  formula  into: 


VH,M.cptr(M(ri),ar)  D  M(rj)  e{  f  |  f  Gdom('P)  A*P(f )  =  ar} 


and  statically  calculates  the  address  set  on  the  right  side  using  the  global  code  heap  spec¬ 
ification  'PG.  It  can  then  define: 


cptr(f,a)  =  f  £  {  f'  |  f'e  dom('I'G)  A*PG(f/)  =  a}. 


This  is  clearly  not  satisfactory  as  the  actual  definition  of  cptr(f,a)  no  longer  refers  to  a! 
Instead,  it  will  be  in  the  form  of  f  €  {f  1, . . . ,  f  „},  which  is  not  modular  and  very  hard  to 
reason  about. 

Taking  the  modularity  issue  more  seriously,  from  the  JMP  rule  again,  we  notice  that 
all  ECPs  it  can  jump  to  are  those  contained  in  the  current  local  VP  only.  Since  the  CAP  lan¬ 
guage  presented  in  previous  section  supports  separate  verification  through  linking  rule 
LINK,  when  checking  each  module's  code  heap,  we  do  not  have  the  global  specification 
y¥c  and  only  have  the  declared  import  interface  lP/v .  For  our  example,  checking  the  code 
blocks  under  different  organizations  of  modules  would  result  in  different  ai  assertions: 


k(H,M).M(ri)e{fi} 


when  f  1  and  ±2  are  in  a  same  module 


and  there  is  no  other  block  with  precondition  a,  in  it; 


X(H,M).M(ri)  E{f  1 , f 3} 


when  f  1  and  f2  are  in  a  same  module 


and  there  is  a  block  f  3  also  with  precondition  a,  in  it; 


k(H,M).M(ri)6{} 


when  f  1  and  f  2  are  not  in  a  same  module 


and  there  is  no  other  block  with  precondition  ar  in  f  2  module; 


X(M,R).R(r1)G{f3} 


when  f  1  and  f  2  are  not  in  a  same  module 


and  there  is  a  block  f  3  also  with  precondition  a;  in  f  2  module. 
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Since  we  usually  do  not  know  the  target  addresses  statically,  we  cannot  put  all  possible 
indirect  code  pointers  into  the  import  specification  'F/JV .  The  syntactic  approach  used  by 
CAP  cannot  support  general  ECPs  without  resorting  to  the  whole-program  analysis.  This 
greatly  limits  CAP's  modularity  and  expressive  power. 

Challenges.  Given  the  ECP  problem  explained  so  far,  we  can  summarize  some  impor¬ 
tant  criteria  for  evaluating  its  possible  solutions: 

•  Is  it  expressive?  The  new  system  should  retain  all  expressive  power  from  CAP.  In 
particular,  we  still  want  to  write  assertions  as  general  logic  predicates.  Ideally,  there 
should  be  a  "type-preserving"  translation  from  CAP  into  the  new  system. 

•  Is  it  easy  to  specify?  The  specifications  should  be  self-explanatory  and  can  be  used  to 
reason  about  safety  properties  directly.  There  should  be  no  need  of  translating  ECP 
specifications  into  less  informative  forms  such  as  indexed  assertions  or  addresses 
sets  as  found  in  approaches  aforementioned. 

•  Is  it  modular?  The  specifications  should  be  independently  writable  and  ECPs  can 
be  freely  passed  across  the  modular  boundaries. 

•  Is  it  simple?  The  approach  should  better  not  involve  overwhelming  efforts  in  design 
and  implementation  when  compared  to  CAP.  It  should  not  alter  or  pollute  the  basic 
structure  of  Hoare-style  program  derivations  and  assertions. 

•  Can  it  support  extensions  easily?  The  approach  should  work  smoothly  with  com¬ 
mon  language  features  and  popular  extensions  to  Hoare  logic. 


3.2  Extended  Propositions 

To  avoid  the  "circular  specification"  problem  in  the  syntactic  approach  (to  ECP),  we  break 
the  loop  by  adding  a  small  amount  of  syntax  to  the  assertion  language,  and  then  split 
the  syntax  of  assertions  from  their  "meanings"  (or  validities).  The  key  idea  here  is  to 
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delay  the  checking  of  the  well-formedness  property  of  ECPs.  Instead  of  checking  them 
individually  at  the  instruction  sequence  level  using  locally  available  specification  lF/v,  we 
collect  all  these  checks  into  one  global  condition  that  would  only  need  to  be  established 
with  respect  to  the  global  code  heap  specification  'Fg  when  all  code  are  finally  linked 
together  before  execution. 

Basically  cptr  is  now  merely  a  syntactic  constant  and  can  appear  in  any  assertion  at 
any  time  in  the  form  of  cptr(f,a).  Its  meaning  (or  validity)  is  not  revealed  during  the 
verification  of  local  modules  ( i.e .,  the  well-formed  instruction  sequence  rules).  An  "inter¬ 
pretation"  will  translate  the  ECP  assertion  syntax  into  its  meaning  (as  a  meta  proposition) 
when  the  global  code  heap  specification  'Pg  is  finally  available  in  the  top-level  PROG  rule. 
The  PROG  rule  will  then  complete  the  well-formedness  check  for  the  whole  program.  We 
achieve  modularity  through  this  two-stage  verification  structure. 

Note  that  requiring  the  global  specification  in  the  PROG  rule  does  not  break  any 
modularity,  since  at  runtime  all  code  (and  their  specifications)  must  be  made  available 
before  they  can  be  executed.  Besides,  the  top-level  rule  PROG  only  needs  to  be  validated 
once  for  the  initial  machine  configuration. 

Extended  propositions.  Figure  3.1  defines  extended  logical  propositions  ( PropX ).  PropX  can 
be  viewed  as  a  lifted  version  of  the  meta  logic  propositions,  extended  with  an  additional 
cptr  constant:  the  base  case  (p)  is  just  the  lifted  proposition  p  (thus  PropX  retains  the  full 
expressive  power  of  meta  logic  propositions);  cptr  is  the  constructor  for  specifying  ECP 
propositions.  To  interoperate  lifted  propositions  and  ECP  propositions,  we  also  lift  all  the 
logical  connectives  and  quantifiers. 

For  the  universal  and  existential  quantifications,  we  use  higher-order  abstract  syn¬ 
tax  (HO AS)  [52]  to  represent  them.  For  example,  W.r:A.P  is  actually  implemented  as 
W(Ajc  :A.  P).  The  benefit  here  is  that  we  can  utilize  the  full  expressive  power  of  the  mecha¬ 
nized  meta  logic  (CiC/  Coq)  and  use  a  single  quantifier  to  quantify  over  all  possible  types 
(A)  such  as  Prop,  State,  and  even  State  — >  Prop. 
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(. PropX )  P,  Q 


(. Assertion )  a 


:=  (p) 

lifted  meta  proposition 

I  cptr(f ,  a 

)  embedded  code  pointer 

|  PAQ 

con  junction 

|  PVQ 

disjunction 

|  P-*Q 

implication 

|  Vv:A.P 

universal  quantification 

|  3x:A.P 

existential  quantification 

G  State  — > 

PropX 

Figure  3.1:  Extended  propositions 


l(p)h  = 

[[cptr(f  ,a)]]«j,  ^ 

[[PAQ]]vj(  = 

[[PVQ]W  4 

Ip-Q]W  = 

[¥jc:A.P]]ii,  = 
pxiA.P]]^  = 


P 

f  Gdom('F)A'P(f)  =  a 
[[P]]>j<  A  [Q]«j( 

[[  p  ]]  'p  v 
[[Plk-Dp]]* 
VB:AjP[B/x}]}y 
IB-.A.lPlB/x)}^ 


Figure  3.2:  Interpretations  of  extended  propositions 

Extended  propositions  can  be  used  to  construct  "extended"  predicates  using  the  ab¬ 
straction  facility  in  the  underlying  meta  logic.  For  example,  the  following  extended  state 
predicate  of  type  State  -^PropX  says  registers  r  |  and  r2  store  the  same  value,  while  1-3 
stores  a  non-NULL  value: 

(R(ri)  =  M(r2)  AM(r2)  7^  NULL). 

Extended  predicates  are  not  limited  to  be  over  machine  states  only.  For  example,  the  fol¬ 
lowing  extended  value  predicate  resembles  the  code  pointer  type  found  in  type  systems. 
(Here,  a,  the  precondition  of  the  code  pointed  to  by  f ,  is  an  extended  state  predicate.) 

code  a  =  Lf  ,cptr(f  ,a) 

Extended  propositions  adds  a  thin  layer  of  syntax  over  meta  propositions.  Figure  3.2 
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presents  an  interpretation  of  their  validity  in  meta  logic.  It  is  defined  as  a  meta  function. 
A  lifted  proposition  (p)  is  valid  if  p  is  valid  in  the  meta  logic.  Validity  of  ECP  proposi¬ 
tions  can  only  be  testified  with  a  code  heap  specification  *F  (formally  defined  in  the  next 
section),  so  we  make  it  a  parameter  of  the  interpretation  function;  'F  is  typically  instan¬ 
tiated  by  (but  not  limited  to)  the  global  specification  'Fg.  Interpretation  of  cptr(f,a)  tests 
the  equality  of  a  with  *P(f ).  Here  we  use  the  inductively  defined  Coq  equality  eq  (equiv¬ 
alent  to  the  Leibniz'  equality)  extended  with  extensionality  of  functions  (a  safe  extension 
commonly  used  in  the  Coq  [30]  community).  Note  that  the  use  of  equality  predicate  in 
logic  is  different  from  the  use  of  equality  function  in  programming — a  programmer  must 
supply  the  proper  equality  proofs  in  order  to  satisfy  the  ECP  interpretation.  Extended 
logical  connectives  and  quantifiers  are  interpreted  in  a  straight-forward  way.  Note  that 
HO  AS  [52]  is  used  in  the  interpretation  of  extended  implications. 

Interpretation  of  assertions  can  be  trivially  defined  as 

Ia]W  =  AMaS]* 

which  turns  "syntactic"  program  specifications  in  extended  propositions  into  "real"  pro¬ 
gram  invariants  in  the  mechanized  meta  logic. 

3.3  The  XCAP  Framework 

In  this  section,  we  present  a  new  XCAP  framework,  which  is  based  on  CAP  and  uses 
PropX  as  its  assertion  language.  We  refer  readers  to  Section  2.3  for  more  details  on  the 
CAP  framework  and  only  highlight  the  difference  between  XCAP  and  CAP  in  this  section. 

Assertion  Language.  We  present  the  assertion  language  of  XCAP  in  Figure  3.3.  The  only 
difference  between  it  and  Figure  2.4  is  that  assertions  (a)  are  now  defined  as  extended  state 
predicates.  We  also  define  code  heap  specifications  (lF)  and  the  assertion  subsumption 
relation  (=>)  accordingly.  Note  that  assertions  are  first  turned  into  meta  logical  interpreta¬ 
tions  before  doing  subsumptions. 
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(CdH  pSpec)  VP 


::=  {f->a}* 

( Assertion )  a  e  State  —>  PropX 

(Assertlmp)  a=>a7  =  \AF,§.  [[a]^  §  D  [[a7]],j,  § 

(, Steplmp )  a=^a7  =  \AF,§.  [[ a]J»j,  §  D  [[a7]]^  Nextc(§) 

Figure  3.3:  Assertion  language  of  XCAP 

Inference  rules.  To  reason  about  TM  programs  in  XCAP,  just  as  we  did  for  CAP  in  Fig¬ 
ure  2.5,  we  present  a  similar  set  of  inference  rules  for  well-formed  programs,  code  heaps, 
and  instruction  sequences  in  Figure  3.4.  Other  than  the  differences  in  the  assertion  lan¬ 
guage,  we  only  modified  the  PROG  rule  and  the  JMP  rule,  and  added  a  new  ECP  rule 
for  introducing  new  ECP  propositions  into  assertions  on  the  fly.  For  the  unchanged  rules, 
readers  can  refer  to  Section  2.3  for  explanations. 

The  change  for  the  PROG  rule  is  minor  but  important.  Here  we  use  the  global  spec¬ 
ification  XJIC  in  the  interpretation  of  assertions  which  may  contain  ECP  propositions.  For 
state  §  to  satisfy  assertion  a,  we  require  a  proof  for  the  meta  proposition  ([[a]]^  §).  This  is 

G 

the  only  place  in  the  XCAP  inference  rules  where  validity  of  assertions  (with  ECP  proposi¬ 
tions)  needs  to  be  established.  Other  rules  only  require  subsumption  between  assertions. 

For  the  JMP  rule,  instead  of  looking  up  the  target  code  blocks'  preconditions  a7  from 
the  current  (local)  specification  lF,  we  require  the  current  precondition  a  to  guarantee  that 
the  target  code  label  R(r)  is  a  valid  ECP  with  a7  as  its  precondition.  Combined  with  the 
([[a]]vj,  S)  condition  established  in  the  PROG  rule,  we  can  deduce  that  a7  is  indeed  the  one 

G 

specified  in  VPG. 

If  we  call  the  JMP  rule  "consumer"  of  ECP  propositions,  then  the  ECP  rule  can  be 
called  "producer."  It  is  essentially  a  "cast"  rule — it  allows  us  to  introduce  new  ECP  propo¬ 
sitions  cptr(f  ,Y(f ))  about  any  code  label  f  found  in  the  current  code  heap  specification  lP 
into  the  new  assertion  a7.  This  rule  is  often  used  when  we  move  a  constant  code  label  into 
a  register  to  create  an  ECP. 
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(Well-formed  Program) 


^GhC:^G 


(lat  §)  ^{a}I 


1“  {a}  (C,S,I) 


(PROG) 


'PWPC:'P 


(Well-formed  Code  Heap) 

Vf, 


%,v  I"  {f 


(CDHP) 


Vm  I”  Ci  .'Pi  %n2  h  C2  :*P2  ^wl(f)  =  'Pw2(f ) 
dom(Ci)ndom(C2)  =0  Vf  edorn(*P/Jvl)ndom(*P;iv2) 
'PmU'P;Jv2PCiUC2:'PiU'P2 


(link) 


*P  h {a} I  (Well-formed  Instruction  Sequence) 


a=^a'  xPP{a,}I  ce{add,addi,mov,movi,  alloc,  free,  Id,  st} 


^h{a}c;I 

a^-'P(f)  fedomOP) 
*P  h  {a}jd  f 


(SEQ) 


(JD) 


(X(H,M). 

(X(H,M). 


r,)</)Aa(I,R))^a'  'Phja'JI 
r,)>i)  A  a(H,R))^'P(f)  fedomOP) 


*P  V{a} bgti 


(BGTI) 


(X(H,M).  a'  (H,M)  A  cptr(M(r),  a7) ) 


*P  P  {a}jmp  r 


-  (JMP) 


(AS.cptr(f  ,*P(f ))  Aa  §)  =L  a'  fGdom('P) 
'Pl-ja}! 


»Ph{a'}I 


-  (ecp) 


Figure  3.4:  Inference  rules  of  XCAP 
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Example.  Combining  the  JMP  and  ECP  rules,  ECP  knowledge  can  be  built  up  by  one 
module  at  the  time  of  ECP  creation  and  be  passed  around  and  get  used  for  indirect  jumps 
in  other  modules.  For  example,  given  the  following  code  where  we  assume  register  r3o 
contains  the  return  value  and  register  1-31  contains  the  return  code  pointer: 


plus : 

add 

OJ 

O 

rO,  rl; 

// 

fun  plus  (a,  b)  =  a  +  b 

jrap 

r31 

app2: 

mov 

r3, 

rO; 

// 

fun  app2(f,  a,  b)  =  f(a 

mov 

rO, 

rl; 

mov 

rl. 

r2; 

jmp 

r3 

we  can  assign  them  with  the  following  XCAP  specifications  and  make  safe  (higher-order) 
function  calls  such  as  app2(plus,l,2). 

{plus 

(M(ro)  =a  AM(ri)  =b  AR(r3i)  =  ret) 

Acptr(ret,  (R'(r3o)  =  a  +  b))} 

{app2  X(H, R) .  3/,  a,  b,  ret. 

(M(rj)  =a  AM(r2)  =b  AM(ro)  =/  AR(r3i)  =ret) 

Acptr (/, 

(R7(ro)  =  d  AM7(ri)  =  b'  AR7(r3i)  =  ret') 

A cptr [ret',  X(H" ,  R") .  (R"  (r30)  =  a'  +  b') ) ) 

Acptr  (ret,  X(H',R').  (R'(r3o)  =a  +  b))} 

Soundness.  The  soundness  of  XCAP  is  proved  in  the  same  way  as  we  did  for  CAP  We 
give  the  main  lemmas  and  a  proof  sketch  here.  More  details  can  be  found  in  Appendix  B. 

Lemma  3.1  (XCAP  Progress) 

If  'Pg  h  {a}  P,  then  there  exists  a  program  P'  such  that  P  1 — >  P'. 

Proof  Sketch:  Suppose  P=  (C,S,  I),  by  inversion  we  obtain  XPG  b{a}L  The  proof  is  by 
induction  over  this  derivation.  ■ 
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Lemma  3.2  (XCAP  Preservation) 

If  'Pg  F  {a}  P  and  P  i — *  P'  then  there  exists  an  assertion  a7  such  that  PG  h{a'}P'. 

Proof  Sketch:  Suppose  P=  (C,S,I);  by  inversion  we  obtain  'Pg  h  Ci'Pg,  ([ajj^  §),  and 

G 

'Pg  h  {a} I.  We  do  induction  over  derivation  vPf.  h  {a} I.  The  only  interesting  cases  are  the 
JMP  and  ECP  rules. 

For  the  JMP  rule  case,  let  §  be  (H,M).  By  the  implication  a  =J>  (X(H,M).cptr(M(r),  a7)) 
and  the  interpretation  of  cptr  it  follows  that  a7  =  xPG(M(r))  and  M(r)  Gdom('Pc).  Then  by 
the  same  code  heap  typing  lemma  as  discussed  in  Section  2.3,  it  follows  that 
XPC  F  (a7}C(M(r)).  Finally  by  a  =>  a7  it  follows  that  a7(H,M). 

For  the  ECP  case,  by  the  code  heap  typing  lemma  and  by 
(XS.cptr(f  ,T'G(f))  A  a  S)  =>  a7  it  follows  that  [[a7  S]]^,  .  Also  we  have  'Pg  F{a7}I.  Then  we 

G 

use  the  induction  hypodissertation  to  finish  the  proof.  ■ 

Theorem  3.3  (XCAP  Soundness) 

If  'Pg  F  {a}  P,  then  for  all  natural  number  n,  there  exists  a  program  P7  such  that  Pi — >n  P7. 

3.4  Discussion 

The  main  idea  of  XCAP  is  to  support  Hoare-style  reasoning  of  ECPs  by  extending  the 
assertion  language  with  a  thin  layer  of  syntax.  Next  we  review  XCAP  using  the  criteria 
given  in  Section  3.1.  The  following  theorem  presents  a  simple  "type-preserving"  transla¬ 
tion  from  CAP  to  XCAP  and  shows  that  XCAP  is  at  least  as  powerful  as  CAP.  To  avoid 
confusion,  we  use  \~cap  and  \~xcap  to  represent  CAP  judgments  (as  defined  in  Figure  2.4) 
and  XCAP  ones  (as  defined  in  Figure  3.4).  See  our  implementation  for  detailed  proofs. 

Theorem  3.4  (CAP  to  XCAP  Translation) 

We  define  the  lifting  of  CAP  assertions  and  specifications  as: 

ran  =  XS.  (a  S) 

and  r{f1'^ai,...,f„^a„}n  =  {f  !-Wain, . . . ,  f„^ra„'1}. 
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1.  If  x¥g  hCAP{a}P  then  rxF0n  hfC4p{ra~l}P; 


2.  if  F cap  C :  ¥  then  r^;,P  h xcap  {C}  r^; 

3.  if  *P  h cap  {a}  I  then  r'h~l  h xcap  {ran}  I 

Proof  Sketch:  (1)  and  (2)  are  straight  forward  and  based  on  (3).  For  (3),  as  CAP's  JMP 
rule  only  reasons  about  preconditions  in  the  current  VP,  we  use  ECP  rule  on  all  pairs  of 
code  label  and  precondition  in  VF  and  use  XCAP's  JMP  rule  to  finish  the  proof.  ■ 

The  specification  written  in  XCAP  assertion  language  is  close  to  a  typical  Hoare  asser¬ 
tion  and  thus  is  easy  to  write  and  reason  about.  From  a  user  perspective,  there  is  no  need 
to  worry  about  the  "meaning"  of  the  ECP  propositions  because  they  are  treated  abstractly 
almost  all  the  time. 

XCAP  is  still  lightweight  because  the  lifted  propositions  (p)  and  their  reasoning  are 
shallowly  embedded  into  the  meta  logic,  which  is  the  same  as  CAP.  The  added  component 
of  ECP  propositions  as  well  as  other  lifted  connectives  and  quantifiers  are  simple  syntactic 
constructs  and  do  not  involve  complex  constructions. 

As  we  will  show  in  later  chapters,  the  XCAP  framework  can  be  easily  extended  to 
support  other  language  features  and  popular  extensions  of  Hoare  logic. 
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Chapter  4 


Impredicative  Polymorphisms  and 
Recursive  Specifications 

The  XCAP  system  presented  in  the  previous  chapter  enjoys  great  expressive  power  from 
its  underlying  meta  logic.  As  the  mini  examples  shown  before,  features  such  as  data 
polymorphism  can  be  easily  supported.  However,  to  support  modular  verification,  when 
composing  specifications,  it  is  important  to  be  able  to  abstract  out  and  quantify  over  (part 
of)  the  specifications  themselves.  This  is  especially  important  for  ECPs,  since  very  often 
the  specification  for  the  target  code  is  only  partially  disclosed  to  the  callers.  We  extend  the 
XCAP  from  the  previous  chapter  to  support  this  kind  of  impredicative  polymorphism. 

Using  the  extended  XCAP,  we  solve  the  ECP  problem  for  separation  logic  [54]  and 
present  a  verification  of  a  destructive  list-append  function  listed  as  an  example  in  [54], 

Recursive  specifications  are  very  useful  in  describing  complex  invariants.  Simple  re¬ 
cursive  data  structures  such  as  link-list  are  already  supported  by  XCAP.  However,  for 
the  recursive  types  (,ua.  t)  found  in  type  systems,  their  counterpart  in  logic,  "recursive 
predicates",  can  not  be  easily  defined  in  XCAP.  We  follow  the  extension  for  impredicative 
polymorphisms  and  extended  XCAP  to  support  recursive  specifications. 

Both  the  extensions  cause  very  little  change  in  the  XCAP  inference  rules  and  meta 
theory.  Thus  they  are  light-weight  and  proved  sound. 
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4.1  Impredicative  Polymorphisms  and  Recursive  Specifications 


Impredicative  polymorphisms  and  recursive  types  can  be  easily  supported  in  type  sys¬ 
tems.  Take  TAL  [41]  for  example,  it  allows  quantifications  over  value  types,  which  corre¬ 
spond  to  value  predicates  in  XCAP.  Since  XCAP  predicates  are  much  more  flexible  than 
types,  we  choose  to  support  universal  and  existential  quantifications  over  arbitrary  ex¬ 
tended  predicates  of  type  A— >PropX  (where  A  does  not  contain  PropX).  We  reuse  the 
quantifiers  defined  in  XCAP  in  Section  3.3  and  write  impredicative  extended  proposi¬ 
tions  as  follows: 


Va:A  — >PropX.  P  and  3a:A— s-PropX.P. 

In  the  implementation  of  these  impredicative  quantifiers,  the  HOAS  technique  used 
for  predicative  ones  no  longer  works  because  of  the  negative-occurrence  restriction  for 
inductive  definitions.  We  use  the  de  Bruijn  notations  [15]  to  encode  the  impredicative 
quantifiers.  For  more  details,  see  Appendix  8. 

The  next  task  is  to  find  a  way  to  establish  the  validity  of  impredicative  extended 
propositions.  One  obvious  idea  is  to  take  the  previously  defined  interpretation  function 
in  Figure  3.2  and  directly  apply  it  to  the  impredicative  quantification  cases  as  follows: 

[[  ¥  a :  A  ^PropX.  P  ]]  ^  =  Va:A^PropX.[[P[a/a]]],j, 

[3a:A^PrapX.P]]¥  =  3a : A ^PropX.  [[P [a/a] }}^ 

Unfortunately  (but  not  surprisingly),  the  recursive  call  parameter  P[a/a]  may  be  larger 
than  the  original  ones  as  a  can  bring  in  unbounded  new  sub-formulas.  The  interpretation 
function  no  longer  terminates,  and  thus  is  not  definable  in  the  meta  logic. 

Our  solution  is  to  define  the  interpretation  of  extended  propositions  as  the  set  of  induc¬ 
tively  defined  validity  rules  shown  in  Figure  4.1.  We  define  an  environment  of  extended 
propositions  as 

(env)  r  :=  •  |  r,P 
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F  hvF  p  ( Validity  of  Extended  Propositions ) 

(The  following  presentation  omits  the  in  judgment  F  b>p  P.) 


per 


rbp 

'P(f)  =  a 


(env) 


r  b(P) 


(O-i) 


rb (p)  P  d  (rbq) 


(CP-I) 


rbq 

r bcptr(f , a)  pF(f)  =  a)  D  (rbq) 


Tbcptr(f,a 

rbp  rbq 


rbp 


(V-Il) 


(A-I) 

rbq 


rbPAq 

rbp 


rbq 


( A-El) 


(O-E) 

(CP-E) 


(A-E2) 


r 

r,Pbq 


(¥-12) 


rbq 

r,pbR  r,qbR 


(— i) 


rbp^q 

r  bP[fi/v]  VB:A 
Fh¥x:A.P 

B:A  I>P[B/*] 

rh3^:A.P  (M) 

rbP[a/a]  Va  :A^PropX 

■.A^PropX.  P 


rbR 

rbp^q  rbp  ,  ^ 

- fFq - (^E) 

r  bWv:A.  P  B:A 


(¥-E) 


rpp[BA]  (V-E1) 

rblrA.P  r,P[fi/jc]bq  \/B:A 

rbq 

a  -.A^PropX  TbP[a/a] 

r\~3a:A->PropX.P 


(3e1) 

(3-12) 


Figure  4.1:  Validity  rules  for  impredicative  extended  propositions 

The  judgment,  F  P,  means  that  P  is  valid  under  environment  F  and  code  heap  speci¬ 
fication  \P.  An  extended  proposition  is  valid  if  it  is  in  the  environment.  Constructors  of 
extended  propositions  have  their  introduction  and  elimination  rules.  The  introduction 
rules  of  lifted  proposition  (p)  and  ECP  proposition  cptr(f.a)  require  that  p  and  'T(f)  =  a 
be  valid  in  the  meta  logic.  Their  elimination  rules  allow  full  meta-implication  power  in 
constructing  derivations  of  validity  of  the  new  extended  propositions.  The  rules  for  other 
constructors  are  standard  and  require  little  explanation. 

The  interpretation  of  extended  propositions  can  be  now  be  simply  defined  as  their 
validity  under  the  empty  environment. 
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m*  =  • n-  p 


Given  the  above  definitions  of  interpretation  and  validity,  we  have  proved  the  follow¬ 
ing  soundness  theorem  (with  respect  to  CiC/  Coq)  using  the  syntactic  normalization  proof 
method  by  Pfenning  [51].  For  proof  details,  see  Appendix  A. 

Theorem  4.1  (Soundness  of  PropX  Interpretation) 

1-  If  I  {p)  W  then  p; 

2.  if  Jcptr(f  ,a)Jq,  then  'P(f)  =  a; 

3.  if  [[P  AQ]]¥  then  [[P]]^  and  [[Q]]¥; 

4.  if  [[ P ¥  Q ]]>j,  then  either  [[Pj^or  [Q]]^; 

5.  if  [[P  — » Q  ]] ^  and  [P]^  then  [Q  ]],*,; 

6.  if  [¥jc:A.P]]t  and  B:A  then  |]P[B/v]]]¥; 

7.  if  [  3  x :  A .  P  ]]  ^  then  there  exists  B :  A  such  that  [  P  [B/x]  ]] 

8.  if  j¥a:A— >PropX.  P]]^  and  a:A— >PropX  then  [[Pfa/a]]]^; 

9.  if  l3a:A^PropX.  P]]^  then  there  exists  a :A—>PropX  such  that  [P[a/a]]]^. 

Corollary  4.2  (Consistency)  [[  (False)  ]]^,  is  not  provable. 

To  make  impredicative  extended  propositions  easy  to  use,  in  the  implementation  of 
PropX  and  its  interpretation,  we  define  additional  concrete  syntax  and  proof  tactics  to  hide 
the  de  Bruijn  representation  and  the  interpretation  detail.  A  user  can  mostly  manipulate 
PropX  objects  in  the  same  way  as  with  Prop  objects  in  Coq.  See  Chapter  8  for  more  details. 

Inference  rules  and  soundness.  The  XCAP  indirect  jump  rule  JMP  from  the  one  pre¬ 
sented  in  Figure  3.4  can  now  be  viewed  as: 
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(X(H,M).  3a'.  (a'  (H,K)  A  cptr(R(r), a'))) 


(jMP). 


vPb{a}jmp  r 

The  existential  quantification  over  the  assertion  a'  (for  the  target  code  block)  is  moved 
from  beging  (implicitly)  over  the  whole  rule  to  being  after  the  assertion  subsumption 
(=^).  This  change  is  important  to  support  polymorphic  code — the  target  assertion  a'  can 
now  depend  on  the  current  assertion  a. 

All  other  inference  rules  of  XCAP  remain  unchanged.  The  soundness  of  XCAP  infer¬ 
ence  rules  (Theorem  3.3)  and  the  CAP  to  XCAP  translation  (Theorem  3.4)  only  need  trivial 
modifications  in  the  case  of  indirect  jump.  We  do  not  restate  them  here. 


Example.  With  impredicative  quantifications,  ECP  can  now  be  specified  and  used  with 
great  flexibility.  For  example,  the  app2  function  in  Section  3.3  can  now  be  assigned  with 
the  following  more  general  specification.  Instead  of  being  restricted  to  an  argument  with 
the  "plus"  functionality,  any  functions  that  take  two  arguments  a  and  b  and  return  a  value 
satisfying  (unrestricted)  assertion  a ret(a,b)  can  be  passed  to  appl. 

{app2  ^  X(H,  M) .  3  f,  a ,  b ,  ret ,  aref . 

(M(ri)  =a  AM(r2)  =b  AM(ro)  =/ AM(r3i)  =ret) 

Acptr (/,  X(H',M'). 3a', b', ret'. 

(M'(ro)  =fl'AK'(ri)  =  b'  AM'(r3i)  =ret') 

Acptr  (ret',  a  ret(a',b'))) 

Acptr  (ret,  a  ret(a,b))} 

Subtyping  on  ECP  propositions.  The  ECP  proposition  has  a  very  rigid  interpretation. 
To  establish  the  validity  of  cptr(f,a),  'P(f)  must  be  "equal"  to  a.  This  is  simple  for  the 
system,  but  is  restrictive  in  usage  and  differs  from  typical  type  systems  where  subtyping 
can  be  used  to  relax  code  types.  With  the  support  of  impredicative  quantifications,  instead 
of  directly  using  cptr,  we  can  define  a  more  flexible  predicate  for  ECPs: 

codeptr(f  ,a)  A  3a'.(cptr(f,a')  AVS.aS— »a'  §). 
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We  can  define  the  following  subtyping  lemma  for  ECP  predicates. 


Lemma  4.3  (Subtyping  of  ECP  Propositions) 

If  [[codeptr(f  ,a7)]]^  and  [[VS.aS  — »a'  S]]^  then  [[codeptr(f  ,a)]])p. 

Proof:  From  [[codeptr(f ,  a')  p  it  follows  that 

pa".  (cptr(f ,  a")  AVS. a'  § -» a"  §) p. 

By  the  soundness  of  interpretation  theorem  it  follows  that 

3a".  [[cptr(f  ,a")]]q,  A  [VS. a'  S— »a"  §]]¥. 

Using  the  ¥-ll,  V-El,  — »-l,  and  — »-E  rules  it  follows  that 

[[VS.aS— » a"  Sp 

Using  the  A  -I  and  3- 1 2  rules  it  follows  that 

pa".  (cptr(f , a")  AVS.aS— »a"  S)]]¥. 

Which  is  [[codeptr(f  ,a)]]T.  ■ 

4.2  Solving  Reynolds's  ECP  Problem 

Separation  logic  [54]  is  a  recent  Hoare-logic  framework  designed  for  reasoning  about 
shared  mutable  data  structures.  Reynolds  [54]  listed  supporting  ECPs  as  a  major  open 
problem  for  separation  logic.  In  this  section,  we  show  how  to  solve  this  problem  within 
the  XCAP  framework  (with  impredicative  polymorphisms  support). 

XCAP  directly  supports  separation  logic  specifications  and  reasoning  by  defining  their 
constructs  and  inference  rules  in  the  assertion  language  and  meta  logic  as  macros  and 
lemmas.  For  example,  the  following  are  some  separation  logic  primitives  defined  over 
the  data  heap  (assuming  l±J  is  the  disjoint  union): 
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emp  =  AH.  (dom(BI)  =  {}) 

1 1 — >  w  =  AH.  (dom(BI)  =  {1}  Ai(l)  =w) 


A 


AH.  (3w.  (l^wH)) 


A 


AH.  3 Mi, Ho.  (Hitt)H2  =  M)  A ai  Hi  A ao  H2 


ai  *  a2 


The  frame  rule  can  be  defined  as  lemmas  (derived  rules)  in  XCAP: 

a  =>  fa'  o  Next/- ) 


iris./\!ViE-INSTR) 


{f1~>a1,...,f„~>an}  h{a}I 


(FRAME-ISEQ) 


{f  1  ~»-ai  *  a', . . .  ,f„'^-a„  *  a'}  b  {a*  a'} I 


ECP  formulas  can  appear  freely  in  these  assertions  and  rules,  thus  it  is  very  convenient  to 
write  specifications  and  reason  about  shared  mutable  data  structures  and  embedded  code 
pointers  simultaneously  Note  that  it  is  assumed  that  in  the  derivations  in  the  FRAME- 
ISEQ  rule,  there  is  no  ECP  or  JMP  rules  being  used. 

Example:  destructive  list-append  function  in  CPS.  To  demonstrate  the  above  point, 
we  verify  a  destructive  version  of  the  list-append  example  which  Reynolds  [54]  used  to 
define  the  ECP  open  problem.  Following  Reynolds,  our  destructive  list-append  function 
is  written  in  continuation  passing  style  (CPS): 


appendix,  y,  rk )  = 

if  x  ==  NULL  then  rk  (y ) 

else  let  k{z)  =  ([e  +  1]  :=  z ;  rkix )) 


in  append  (  [cc  +  1]  ,  y,  k) 


Here  the  append  function  takes  three  arguments:  two  lists  x  and  y  and  a  return  contin¬ 
uation  rk.  If  x  is  an  empty  list,  it  calls  rk  with  list  y.  Otherwise,  it  first  creates  a  new 
continuation  function  k  which  takes  an  (appended)  list  z,  makes  list  x's  head  node  link  to 
z,  and  passes  the  newly  formed  list  (which  is  pointed  to  by  x)  to  the  return  continuation  rk. 
Variables  x  and  rk  form  the  closure  environment  for  continuation  function  k.  The  append 
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function  then  recursively  calls  itself  with  the  tail  of  list  x,  list  y,  and  the  new  continuation 
k.  For  node  x,  [x]  is  its  data  and  [x+  1]  is  the  link  to  the  next  node. 

We  do  closure  conversion  and  translate  append  into  TM  assembly  code.  In  the  presen¬ 
tation,  we  often  write  a  for  assertion  X(HI,M).  3;q  \A\ , . . .  ,xn  :An.  a,  so  all  free  variables  in  a 
are  existentially  quantified  right  after  the  lambda  abstraction.  Formulas  such  as  (a  *  a7  H) 
and  M(r)  =  w  are  also  simplified  to  be  written  as  a  *  a7  and  r  =  w. 

Predicate  (list  Is  1)  describes  a  linked  list  pointed  to  by  1  where  the  data  cell  of  each 
node  stores  the  value  in  Is  respectively.  Here  Is  is  a  mathematical  list  where  nil,  w ::  Is  and 
ls-\-+lt  stand  for  the  cases  of  empty  list,  cons,  and  append,  respectively. 

list  nil  1  =  emp  A  (l  =  NULL) 
list  (w ::  Zs)  1  =  317.1h->w,1/  *  list  /v  l7 


I 


nth  (Is ,  1) 

n th ( Is ,  2) 

nth ( Is ,  n) 

j * 

/  *  .  /  * 

r 

1" 

NULL 

Predicate  (cont  aenv  Is  f )  requires  f  to  point  to  a  continuation  code  block  which  expects 
an  environment  of  type  aenv  and  a  list  which  stores  Is. 

cont  ae,lv  Zs  f  =  codeptr(f,  XS.3<?«v,z.  (ro  =  env  A  ri  =z)  A  aem,  env  *  list/sz) 


Predicate  (clos  Is  1)  describes  a  continuation  closure  pointed  to  by  1;  this  closure  is  a 
pair  ( cnt,env )  where  cnt  is  a  continuation  function  pointer  and  env  points  to  an  environ¬ 
ment  for  cnt.  The  environment  predicate  aenv  is  hidden  inside  the  closure  predicate, 
clos  Is  1  =  3a  em,  cnt,  env.  1^-cnt  ,env  *  aenv  env  A  cont  a  env  Is  cnt 


i 


cnt 

env 

- ►!  environ ment  of  type  aenv 

continuation  code  block 

expecting  an  environme 
v  and  a  list  stores  Is 


5 


In  Figure  4.2  and  Figure  4.3,  we  list  the  precondition  for  each  instruction  on  its  right 
side.  The  instruction  determines  which  well-formed  instruction  rule  to  use  at  each  step. 
State  diagrams  are  drawn  before  all  the  interesting  steps. 
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env 

X 

a 

z 

- ►]  linked  list  stores  Is  | 

rk 

- ►!  closure  expecting  a  list  stores  a::ls  | 

_ 

{(ro  =  env  At\=z  )  A  list  Is  z  *  x\ — >a,_  *  clos  (a ::  Is)  rk  *  em'i— >x,  } 

k  :  Id  r2 ,  rO (0) 

{( . Ar2=x  )A .  *  envt-^- _,rk} 

Id  r3,  rO(l) 

{( . Ari  =  rk)A .  *  env 

free  rO,  2 

{(  . )  A . > 

st  r2(l) ,  rl 

{(  . }  A .  *  xi —>a,z  *  . } 

mov  rl,  r2 


{(  ri=xAr3  =  r£  )  Alist  (a::ls)  x  *  aenv  env’  A  contaem.  (a::  Is)  cnt  *  rfc  i— >  cnf,  env  ’ } 

Id  r31,  r3(0) 

{(  . Ar3i=c«/)A .  *  rki-^  _,env’ } 

Id  rO,  r3(l) 

{(ro  =  env’A . )A .  *rki— > 


rO 

rl 

r31 


free  r3,  2 

K  environment  of  type  ae, 


linked  list  stores  a::ls 


rO  env1  — environment  of  type  aer 


continuation  code  block 


-►]  linked  list  stores  a::ls 


{(ro  =  e«v’ Ari  =x 

jmp  r31 


A  r3i=  cnt)  A  list  (a :: /s)  x  *  aenv  env’  Acont  aenv  (a::  Is)  cnt} 


Figure  4.2:  Code,  specification,  and  illustration  of  the  list  append  function 
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{(ro=x  f\r\=y  f\T2  =  rk  )Alist/sx  *  list  y  *  clos  (ls++lt)  rk} 

//  the  following  ‘‘ then ’’  branch  is  almost  same  as  the  second  half  of  function  k 
append:  bgti  rO,  0,  else 


{(  n=y/\T2  =  rk  ), 

Id  r31 ,  r2 (0) 

{(  . /\T2\=cnt) , 

Id  rO,  r2(l) 

{(ro  =  e«vA . ) , 

free  r2,  2 

{(ro  =  e«vAri  =y  Ar-}i  =  cnt) , 

jmp  r31 


list/fy  *  aenv  env  A  cont  aenv  It  cnt  *  rk<-^cnt,env} 

.  *  rk i— >  _,en\'} 

.  *  rk\— > 

list  It  y  *  aenv  env  A  cont  aenv  It  cnt } 


{(ro=xA  ri  =y  /\T2  =  rk  )  A  list  Is  b*  list  It  y  *  clos  (a::ls++lt)  rk  *Xf—>a,b} 

else  :  alloc  r3,  2 

{( .  Ar 3  =  env)  A . *env 

st  r3(0) ,  rO 

{( . )  A . *env  i— >x,_} 

st  r3(l) ,  r2 

{( .  A . )A . *envt— >x,  rk} 

Id  rO,  rO (1) 

{(ro  =  bA .  A . )A . *xi— >a,_* . > 

alloc  r2,  2 


{< 

{( 

{< 


rO 

ri 

r2 


. /\T2  =  nkA . )A .  *nk 

st  r2(l) ,  r3 

.  )  A . *nk\— >  _,env} 

movi  r3 ,  k 


. Ar3  =  £)  A . > 

st  r2 (0) ,  r3 


i(ro  =  b  A  ri  =y  Ar2  =  nk)  A  list  Is  b  *  list  It  y  *  clos  ( a ::  ls++lt)  rk  *  x<—>a,_  *env\-^>x,rk  *  nk\-^k,env} 
//  (ecp)  rule 


rO 

ri 

r2 


{(ro  =  £Ari  =yA  T2  =  nk)  A  list  Is  b  *  list  It  y  *  clos  (ls++lt)  nk > 

//  where  aenv  being  packed  is  defined  as  aenv  env  =  clos  {a ::  ls++lt)  rk  *  xt-^a,_*envt-^>x,rk 
jd  append 


Figure  4.3:  Code,  specification,  and  illustration  of  the  list  append  function  (continued) 
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Our  specification  of  the  append  function  guarantees  that  the  return  continuation  rk  will 
get  a  correctly  appended  list  (i.e.,  the  list  contents  are  exactly  the  same  as  the  two  input 
lists).  Furthermore,  even  though  the  function  contains  a  large  amount  of  heap  allocation, 
mutation,  and  deallocation  (which  are  used  to  build  and  destroy  continuation  closures 
and  to  append  two  lists  on  the  fly),  memory  safety  is  fully  guaranteed  (no  garbage,  no 
illegal  free  operation). 

4.3  Recursive  Specifications 

Recursive  specifications  are  very  useful  in  describing  complex  invariants.  Simple  recur¬ 
sive  data  structures  such  as  link-list  are  already  supported  by  the  inductive  definition 
found  in  Prop.  However,  for  the  recursive  types  (pa.  t)  found  in  TAL,  where  things  such 
as  embedded  code  pointers  can  be  nested  inside  an  inductive  definition,  their  counterpart 
in  logic,  "recursive  predicates",  can  not  be  easily  defined  in  XCAR  We  extend  PropX  to 
support  recursive  predicates  and  use  syntactic  methods  to  establish  validity. 

We  define  the  recursive  predicate  constructor  as  follows. 

(PropX)  P, Q  ::=  . . .  |  (p  a:  A^  PropX. he:  A. P  B) 

To  understand  the  formation  of  recursive  predicate,  we  will  start  from  the  innermost 
proposition  P.  Ajc:A.P  is  a  predicate  of  type  A  — > PropX .  So  pa:A  ~^PropX.he:A.P  is  meant 
to  be  a  recursive  predicate  of  type  A  — >  PropX,  which  corresponds  to  recursive  types  found 
in  type  systems.  Since  the  basic  unit  of  definition  is  extended  proposition  instead  of  ex¬ 
tended  predicate,  we  apply  it  with  a  term  B  of  type  A,  and  make  (p  a:A—>  PropX.  he :  A .  P  B) 
the  basic  shape  of  recursive  predicates  formula.  When  using  recursive  predicates  formu¬ 
las,  we  often  use  its  predicate  form,  and  use  the  notation  pa :  A  — *•  Pro pX .  he :  A .  P  to  repre¬ 
sent  predicate  hy:A.  (p  a\A— > PropX. he:A.P  v). 

To  establish  validity  of  recursive  predicate  formulas,  we  add  the  following  rule  to  the 
validity  rules  in  Figure  4.1.  It  is  essentially  a  fold  rule  for  recursive  types. 
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B:A  r  h  P[B/x]\jia:A  — >  PropX.  Ajc:A.P/a] 
rb  (/ia:A^PropX.?u::A.P  5) 

We  extend  PropX  interpretation  soundness  (Theorem  4.1)  with  the  following  case: 
If  Kfi  a: A— > PropX. he: A. P  then  flP[2?/jt][/ia:A  — >  PropX.  Ajc:A.P/a]]]^,. 


4.4  Discussion 


In  Figure  4.1  we  have  only  included  the  introduction  rules  for  the  two  impredicative  quan¬ 
tifiers.  This  could  cause  confusion  because  from  the  logic  perspective,  missing  the  two 
elimination  rules  would  raise  questions  related  to  the  completeness  of  the  logic.  How¬ 
ever,  despite  its  name,  PropX  is  not  designed  to  be  a  general  (complete)  logic;  it  is  purely 
a  level  of  syntax  laid  upon  the  meta  logic.  While  its  expressive  power  comes  from  the 
lifted  propositions  (p),  the  modular  handling  of  ECPs  and  impredicative  polymorphism 
follows  syntactic  types. 

To  certify  the  examples  in  this  dissertation  (or  any  polymorphic  TAL  programs),  what 
we  need  is  to  establish  the  assertion  subsumption  relation  =>-  between  XCAP  assertions. 
According  to  its  definition,  assertion  subsumption  is  merely  a  meta-implication  between 
validities  of  XCAP  propositions.  Although  in  certain  cases  it  is  possible  to  first  do  all  the 
subsumption  reasoning  in  PropX  and  prove  [[P— »Q]]vj,,  and  then  obtain  the  subsumption 
proof  [P|y  D  [[Q]]«j,  by  Theorem  4.1,  it  is  not  always  possible  due  to  the  lack  of  complete¬ 
ness  for  PropX,  and  is  not  the  way  PropX  should  be  used.  Instead,  one  can  always  follow 
the  diagram  below  in  proving  subsumption  relations  (we  use  the  impredicative  existential 
quantifier  as  an  example): 


[3a.Pl 


'V 


3a.[[P[a/a 


implication 


[3  a.  q  fly 


3 

Cslf" 

HH 

O 

m 

3 

<D 

3 

meta-implication 

3a.[[Q[a/a]lv 
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To  prove  the  intended  "implication"  relation  (the  top  one),  we  first  use  Theorem  4.1  to  turn 
the  source  proposition's  existential  quantification  into  the  meta  one,  from  which  we  can 
do  (flexible)  meta  implications.  Then  we  reconstruct  the  existential  quantification  of  the 
target  proposition  via  the  introduction  rule.  This  way,  the  construction  of  subsumption 
proof  in  meta  logic  does  not  require  the  reasoning  at  the  PropX  level. 

In  fact,  the  subtyping  relation  found  in  TAL  can  be  simulated  by  the  subsumption  re¬ 
lation  in  XCAP  (with  only  the  introduction  rules  for  the  two  impredicative  quantifiers). 
What  the  missing  "elimination  rules"  would  add  is  the  ability  to  support  a  notion  of 
"higher-order  subtyping"  between  "impredicative  types",  which  does  not  appear  in  prac¬ 
tical  type  systems  such  as  TAL,  FLINT,  or  ML.  Although  it  could  be  nice  to  include  such 
a  feature  in  XCAP,  we  did  not  do  so  since  that  would  require  a  complex  semantic  normal¬ 
ization  proof  instead  of  the  simple  syntactic  one  used  for  Theorem  4.1. 

As  we  will  show  in  the  next  Chapter,  this  is  enough  for  reasoning  about  impredicative 
polymorphism  available  in  typical  type  systems.  Translations  from  polymorphic  type 
systems  such  as  TAL  to  XCAP  also  do  not  require  the  elimination  rules. 

Similarly  explanation  applies  to  recursive  specifications,  for  which  only  the  introduc¬ 
tion  rules  are  defined,  too. 
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Chapter  5 


Weak  Updates  and  a  Translation  from 
Typed  Assembly  Language 


Weak  update,  also  termed  as  "general  reference",  is  another  higher-order  features  that 
logic-based  verification  methods  failed  to  support  well.  In  this  chapter  we  first  show  how 
to  extend  the  XCAP  framework  to  support  weak  update,  using  similar  syntactic  technique 
for  the  support  of  ECP  in  Chapter  3. 

We  then  explore  the  relationship  between  XCAP  and  typed  assembly  languages  (TAL). 
TAL  and  CAP/ XCAP  are  suitable  for  different  kinds  of  verification  tasks.  Previously, 
programs  verified  in  either  one  of  them  can  not  interoperate  freely  with  the  other,  making 
it  hard  to  integrate  them  into  a  complete  system.  Moreover,  the  relationship  between  TAL 
and  CAP  lines  of  work  has  not  been  discussed  extensively. 

In  this  chapter,  we  compare  the  type-based  and  logic-based  methods  by  presenting  a 
type-preserving  translation  from  a  TAL  language  to  XCAP.  The  translation  involves  an 
intermediate  step  of  a  "semantic"  TAL  language.  Our  translation  supports  polymorphic 
code,  mutable  reference,  existential,  and  recursive  types.  Since  we  proved  typing  preser¬ 
vation  for  the  translation  from  TAL  to  XCAP,  there  is  a  clear  path  to  link  and  interoper¬ 
ate  well-typed  programs  from  traditional  certifying  compilers  with  certified  libraries  by 
CAP-like  systems. 
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5.1  Weak  Update  in  the  Logical  Setting 


Weak  update  (also  termed  as  "mutable  reference"  or  "general  references")  is  a  commonly 
used  memory  mutation  model.  Examples  of  weak  update  include  ML  reference  cells 
(int  ref)  and  managed  data  pointers  (int  __ gc*)  in  .NET  common  type  system.  In  the  weak 
update  model,  the  value  of  each  memory  cell  must  satisfy  a  certain  fixed  value  type.  The 
tuple  type  in  TAL  (such  as  the  one  to  be  shown  in  next  section)  is  also  a  weak  update 
reference  cell  types. 

Unfortunately,  weak  update  is  not  well-supported  by  CAP  and  other  Hoare-logic- 
based  verification  systems.  The  problem  is  due  to  the  lack  of  a  global  data  heap  invariant 
that  local  assertions  about  heap  cells  can  be  checked  upon.  Existing  Hoare-logic-based 
systems  either  avoid  supporting  weak  update  [44,  64],  limit  the  assertions  (for  reference 
cells)  to  types  only  [28],  or  resort  to  heavyweight  techniques  that  require  the  construction 
of  complex  semantic  models  [9,  2],  In  this  section,  we  present  a  weak  update  extension  of 
the  XCAP  using  the  similar  syntactic  technique  for  ECPs. 

Following  cptr  for  ECP,  We  add  a  reference  cell  proposition  ref(l.t)  to  the  extended 
propositions.  It  associates  word  type  t  (a  value  predicate)  with  data  label  1. 

( PropX )  P,  Q  ::=  ...|ref(l,t) 

( WordTy )  t  €  Word  — >  PropX 

We  can  use  the  following  macro  to  describe  a  record  of  n  cells. 

record(l,ti, . . . ,t„)  =  ref(l,ti)  A  . ..  Aref(l+n— l,t„) 

To  testify  the  validity  of  reference  cell  propositions,  in  the  interpretation  H  P  ^  ^  we 
need  an  additional  "data  heap  specification"  parameter  <f>  which,  similar  to  the  code  heap 
specification  VT,  is  a  partial  mapping  from  data  labels  to  word  types. 

( DtHpSpec )  <f>  ::=  {l^t}* 

To  establish  validity  of  ref(l,t),  data  label  1  and  word  type  t  need  to  be  in  <f>. 
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<*>(!)  =t 


(RF-I) 


rh¥,*ref(l,t)  (<E>(l)=t)D(rhQ) 


(rf-e) 


rbv^cj,  ref(l,t)  v  '  r  hp,®  Q 

Validity  rules  of  other  cases  remain  unchanged  other  than  taking  an  extra  <f>  argument. 
Validity  soundness  of  those  cases  also  holds,  with  the  following  additional  case. 


If  [ref(l,  t)  ]]vj/ cj>  then  <E>(1)  =  t; 

Different  from  code  heap,  the  data  heap  is  dynamic.  Its  specification  can  not  be  ob¬ 
tained  statically.  Instead,  we  need  to  find  it  out  in  each  execution  steps.  So  the  assertion 
interpretation  is  changed  to: 

[[a]]^  =  X(H,M).3<l>,Hi,Hvv.H  =  HiWHvv  A  [[a  (H„M)  A  »F  <f> 

There  should  exist  a  data  heap  specification  <f>  describing  the  weak  update  part  of  current 
data  heap.  Other  than  checking  validity  of  (a  (H,R))  using  lF  and  <f>,  we  also  need  to 
checking  validity  of  <f>. 

For  a  data  heap  specification  <f>  to  be  valid,  each  reference  cell  must  contain  a  value 
that  matches  its  word  type. 

F<FH  =  VlGdom(<J>)  =  dom(M).[[0(l)  11(1)]]^ 

The  extension  of  XCAP  to  support  weak  update  requires  minor  changes  to  the  as¬ 
sertion  languages  and  interpretations,  and  zero  change  to  the  inference  rules.  Thus  the 
soundness  of  XCAP  is  easily  preserved. 

Based  on  the  weak  update  memory  model  defined  above,  we  can  derive  many  useful 
"macro"  inference  rules  as  shown  below.  These  rules  can  help  guide  the  proof  process 
for  the  programmer.  (insens(a,  r)  asserts  predicate  is  insensitive  to  register  r,  i.e.,  does  not 
talk  about  register  r.  Its  definition  is  omitted  here.) 

T1  b  {(X(BI,M).  a(H,M)  A  t  M(rd))}I  insens(a,r,/) 

'F  b  {(X(H,M).  a(H,M)  Aref(M(ri)+w,  t))}  Id  r^,rs(w);I 

Tb{a}I 

- — - (w-st) 

'F  b  {(X(H,M).  a(H,M)  Aref(M(rf/)+w,  t)  A  t  M(ri))}  st  r^w),!^.;!  v 
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Example.  Below  is  a  "mini  object",  using  the  recursive  predicates  and  weak  update  ex¬ 
tensions  presented  in  previous  sections. 

classs  c  { 

void  f  (c  x)  {  x.f(x)  } 

> 

c  =  fi  a:Word  —>PropX.'kx:Word.rei(x,  Xy :  Word.  cptr(y,  A.(H,K).(a  R(rl)))) 

The  above  example  may  look  similar  to  what  one  would  normally  write  in  a  syntactic 
type  system.  However,  given  the  ability  to  write  general  logic  predicate  in  the  specifi¬ 
cations,  it  is  possible  to  compose  interesting  data  structures  and  properties.  Below  is  an 
example:  a  record  pointer  1  which  points  to  an  even  number,  a  data  pointer  to  a  reference 
cell  storing  an  odd  number,  and  a  code  pointer  which,  among  other  things,  expects  reg¬ 
ister  ri  to  be  an  unaliased  pointer  to  a  prime  number,  (here  we  used  the  separation  logic 
primitives  embedded  in  Coq,  as  discussed  in  Section  4.2). 

record(l,  even,  A,w. ref(w,odd),  A,w.cptr(w,  (EHw.M(ri) kuA prime  w)  *...)) 


5.2  Typed  Assembly  Language  (TAL) 

The  TAL  language  presented  here  follows  the  principle  of  the  original  typed  assembly 
languages  [41].  However,  due  to  the  usage  of  TM,  a  untyped  raw  machine,  the  shape  of 
typing  judgments  and  rules  are  slightly  different.  To  simplify  our  presentation,  the  TAL 
in  this  chapter  does  not  directly  deal  with  heap  allocation/ deallocation. 

Type  definitions.  Figure  5.1  presents  the  type  definitions  in  TAL.  Machine  word  is  clas¬ 
sified  as  of  value  type  (x)  including  integer,  code,  tuple,  existential  package,  and  recursive 
data  structures.  A  code  heap  specification  (lT)  is  a  partial  environment  that  maps  a  code 
label  to  a  "precondition"  type  ( [A] .  F)  for  its  corresponding  code  block.  Here  A  is  a  type 
variable  environment  and  T  is  a  register  file  type  which  specifies  the  type  for  each  regis¬ 
ter.  Similarly,  a  data  heap  specification  (<b)  is  a  partial  environment  that  maps  from  a  data 
label  to  a  value  type  for  its  corresponding  heap  cell. 
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{CdHpSpec)  'F  ::=  {f  [Aj.T}* 

(. RfileTy )  r::={r->x}* 

( TyVarEnv )  A  ::=  •  |  a,  A 

( VMordTy )  x  ::=  a  |  int  |  code  [A] .F  |  (xi, . . .  ,x„)  |  3a. x  |  /ra.x 
( DtHpSpec )  <£>  ::=  {l^x}* 


Figure  5.1:  Type  definitions  of  TAL 

Static  semantics.  The  top-level  semantic  rules  of  TAL  are  presented  in  Figure  5.2.  A  pro¬ 
gram  is  well-formed  if  each  of  its  components  is.  For  a  code  heap  to  be  well-formed,  each 
block  in  it  must  be  well-formed.  The  intuition  behind  well-formed  instruction  sequence 
judgment  is  that  if  the  state  satisfies  the  precondition  [A] .  T,  then  executing  I  is  safe  with 
respect  to  lF.  Weakening  is  allowed  to  turn  one  precondition  into  another  provided  that 
they  satisfy  the  subtyping  relation.  A  instruction  sequence  c;I  is  safe  if  one  can  find  an¬ 
other  register  file  type  which  serves  as  both  the  post-condition  of  c  and  the  precondition 
of  I.  A  direct  jump  is  safe  if  the  current  precondition  implies  the  precondition  of  the  target 
code  block  specified  in  lF.  An  indirect  jump  is  safe  when  the  target  register  is  of  a  code 
type  with  a  weaker  precondition.  Constant  code  labels  can  be  moved  into  registers. 

The  subtyping  and  instruction  typing  rules  for  TAL  is  presented  in  Figure  5.3.  Valid 
subtypings  include  dropping  registers,  instantiation  of  code  type,  packing  and  unpacking 
of  existential  packages,  and  folding  and  unfolding  of  recursive  types.  It  allows  jumping 
to  code  blocks  with  stronger  preconditions  than  required. 

For  each  non-control-flow-transfer  instruction  there  is  a  pre/ post-condition  relation 
defined.  When  a  register  is  updated  by  an  instruction,  the  register  file  type  is  also  updated 
by  a  new  value  type.  Arithmetic  instruction  only  operates  on  two  registers  with  integer 
types.  Since  there  is  no  static  data  heap,  a  constant  value  can  only  be  well-formed  under 
an  empty  Heap  type  before  it  can  be  moved  to  a  register.  For  simple  instructions,  their 
pre-  and  post-conditions  do  not  involve  a  change  of  type  variable  environment,  thus  we 
only  specify  the  register  file  types  before  and  after  their  execution.  The  instruction-level 
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^0h{[A].r}p 


(Well-formed  Program ) 


*y0h§:[A].r  ycb{[A].r}i 
^ch{[A].r}(c,s,i) 


(PROG) 


x¥in  b  C :  *F 


(Well-formed  Code  Heap) 


»F/Jvb{'F(f)}C(f)  VfGdom(^) 
^bC:P 


(CDHP) 


’PmbCb'P!  ^2bC2:P2  ^;jvl(f )  =^w2(f ) 

dom(Ci)ndom(C2)  =0  Vf  edom(*F;iVl)ndonn(vF;A,2) 


^jU ^/JV2  b  Ci U  C2 :  'Fi U^2 


(link) 


*F  b  { [A] .  r}  I  (Well-formed  Instruction  Sequence ) 


b  {r}  c  {r}  'Fb{[A].r,}I  ce{add,addi,mov,movi,ld,st} 


'F  b{[A].r}  c;I 

f  Gdom('F)  b^.r^^f) 


(SEQ) 


'Fb{[A].r}jd  f 
r(r)  =  code  [A']  .V  b  [A]  T  <  [A']  .V 


(jD) 


(jMP) 


f  edom(*F) 


'F  b{[A].r}jmp  r 
r(rv)  =  int  'Fb{[A].r}I  b[A].r<»F(f) 


'F  b  { [A] . r }  bgti  rs,  t,  f ;  H 

f  Gdom('P)  *F  b  { [A]  T{  recode  'F(f)}}! 


(bgti) 


'Fb{[A].r}movi  rd,f;I 


(MOVF) 


b  [A]  T  <  [A']  .r  *F  b  { [A']  X'}  I 

»Fb{[A].r}i 


(weaken) 


Figure  5.2:  Top-level  static  semantics  of  TAL 
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b  [A].r<  [A'].r  ( Subtyping ) 


ADA'  V  r  Gdom(r')  r(r)=r'(r)  A' b  r'(r) 

b  [A].r<  [A'].r 

T(r)  =code  fa,A'l.r'  Abx' 


(subt) 


b  [A].T<  [A].r{r:code  [A'] . T [x'/a] } 
r(r)=T[x'/a]  A  b  x' 


(TAPP) 


b  [A].T<  [A].r{r:3a.x} 
r(r)  =  3a.x 


(PACK) 


b  [A].r<  [a,A].r{r:x} 

T(r)  =x[jua.T/a] 

b  [A].r<  [A].r{r:/ia.x} 

T(r)  =/va.x 


b  [A].r  <  [A].r{r:x[/7a.x/a]} 


(unpack) 

(fold) 

(unfold) 


b  {r}  c  {r7}  ( Well-formed  Instruction) 

r(r,)  =  r(rf)  =  int 
b  {r}  add  rrf,rvr?{r{rrf:int}} 

T(rs)  =  int 


b{r}addi  rf,,r„/{r{rrf:int}} 

_ r(r,.)  =  x _ 

b  {r}mov  rrf,rs{r{rrf:x}} 

b{r}movi  rj,w{r{rf/:int}} 

r(r5)  =  (Xl , .  .  .  ,Xw+l ,  •  •  •  J  x„) 


(add) 

(addi) 

(MOV) 

(movi) 

(LD) 


b{r}ld  rrf,rv(w){r{rf/:xw+i}} 

r(  rf/)  —  (Xl ,  •  •  •  ,  Xya-l  , . . .  ,X„)  r(rv )  —  Xy  |  | 


b{r}st  rd(w),r,{r} 


(ST) 


Figure  5.3:  Static  semantics  of  TAL  (subtyping  and  instruction  typing) 


57 


typing  rules  is  not  very  flexible  and  expressive,  e.g.,  pointer  arithmetic  is  not  possible. 

The  typing  rules  for  value  types,  machine  state,  register  file,  data  heap,  and  machine 
word  values  are  presented  in  Figure  5.4.  A  value  type  is  well-formed  only  when  it  contains 
no  free  type  variable  and,  thus,  is  a  ground  type.  The  well-formed  state  rule  instantiates 
the  current  type  variable  environment  and  requires  a  current  data  heap  specification  to  be 
supplied  and  checked.  State  typing  is  done  by  checking  the  Heap  and  register  file's  well- 
formednesses  separately  under  this  heap  specification.  Heap  and  register  file  typing  fur¬ 
ther  break  heap  and  register  file  into  single  word  values,  and  check  their  well-formedness 
individually.  Any  machine  word  value  can  be  typed  as  an  integer.  A  label  can  be  typed 
as  a  tuple  pointer  if  the  cell  types  in  the  heap  type  starting  from  the  label  match  the  cor¬ 
responding  value  types  in  the  tuple  type.  For  a  label  to  be  considered  a  code  pointer,  the 
code  precondition  in  it  has  to  match  the  precondition  listed  in  the  global  context. 

Soundness.  The  soundness  theorem  guarantees  that  given  a  well-formed  program,  the 
machine  will  never  get  stuck.  It  is  proved  following  the  syntactic  approach  of  proving 
type  soundness  [59].  We  also  list  a  few  key  lemmas  below. 

Theorem  5.1  (TAL  Soundness) 

If  VF  F  { [A] .  r}  P,  for  all  natural  number  n,  there  exists  a  program  IP'  such  that  P  i — >"  P7. 

Lemma  5.2  (TAL  State  Weakening) 

If  VF  F  § :  [A] . T  and  b  [A]  ,T  <  [A7].r7  then  ¥  b  S :  [A'].r'. 

Lemma  5.3  (TAL  Instruction  Typing) 

If  T'  b  § :  [A] .  T  and  b  {r}c{r7}  then  »F  b  Nextc  (S) :  [A] .  V. 

5.3  A  "Semantic"  TAL  Language 

Instead  of  doing  translation  from  TAL  to  XCAP  directly,  we  create  a  new  "Semantic"  TAL 
language  (STAL)  to  serve  as  an  intermediate  step  between  them.  Let  us  revisit  the  static 
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A  b  X  'P  h  § :  [A] .  r 


(Well-formed  Type,  State,  Heap,  and  Register  file) 


FTV{x)  CA 
A  b  X 


(type) 


•  b  X,-  V  i 


'F^HR  :r[x1,...,x„/oti,...,a„] 

'Fh(H,R):[a1,...,a„].r 


(state) 


b  H(l)  :4>(1)  V  1  edom(<l>)  =dom(H) 


(heap) 


'P;«I>l-R(r):r(r)  VrCdom(r) 
9b4>bM:r 


(rfile) 


'Fj^bwix 


(Well-formed  Word  Value) 

(int) 


h  w:  int 

f  Gdom('F) 

'FjObf  :code  'f'(f) 

•hx'  'fb  <I>  b  f :  code  [a,  A] .  T 


'f'jObf  :code  [A].r[x'/a 

<J>(l+i-l)  =  x,-  Vi 
'P;<J>bl:(x1,...,xM) 

•hx'  XP;<I>  b  w:x[x'/a] 
¥;<!>  b  w:  3a. x 

xf/;<f>  b  w:x[/ja.x/a] 


(CODE) 

(POLY) 


(tup) 

(ext) 


'FjO  b  v.pa.T 


(REC) 


Figure  5.4:  Static  semantics  of  TAL  (state  and  value  typing) 
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semantics  of  TAL  in  Figure  5.3  and  the  lemmas  used  in  TAL  soundness  proof. 


First,  look  at  the  set  of  subtyping  rules  between  preconditions  ( F  [A] .  F  <  [A'] .  L').  If  we 
also  look  at  the  State  Weakening  lemma  (Lemma  5.2)  in  TAL  soundness  proof,  it  is  easy 
to  see  that  all  of  those  syntactic  rules  are  just  used  for  the  meta  implication  between  the 
two  state  typings  in  the  soundness  proof.  Given  a  mechanized  meta  logic,  we  can  replace 
these  rules  with  a  single  one, 

'FFS:[A].r  D  'FhS:[A'].r'  VS,^ 

F  [A].r<  [A'].r  (SUBT) 

which  explicitly  requests  the  meta  implications  between  two  state  typing.  By  doing  so,  not 
only  did  we  remove  the  fixed  syntactic  subtyping  rules  from  TAL,  but  the  State  Weakening 
lemma  is  no  longer  part  of  the  soundness  proof.  More  importantly,  the  subtyping  between 
preconditions  is  no  longer  limited  to  the  built-in  rules.  Any  valid  implication  relation 
between  state  typing  is  allowed.  This  is  much  more  flexible  and  powerful. 

Now  let  us  look  at  the  set  of  instruction  typing  rules  (F  { T }  c  { T/ } ) .  Also  look  at  the 
Instruction  Typing  lemma  (Lemma  5.3)  in  TAL  soundness  proof.  Again  all  these  syntactic 
rules  are  just  used  for  the  meta  implication  between  two  state  typings  in  the  soundness 
proof.  (The  difference  this  time  is  that  the  two  states  are  now  different  and  are  states 
before  and  after  the  execution  of  an  instruction,  respectively.)  Applying  our  trick  again, 
we  can  replace  these  rules  with  a  single  one, 

xFFS:[A].r  d  'FFNextc(§):[A].r/  VS,^ 


f  {r}c{r'} 


(instr). 


We  also  successfully  removed  the  fixed  syntactic  instruction  typing  rules  as  well  as  he 
Instruction  Typing  lemma  from  TAL.  The  new  form  of  instruction  typing  is  much  more 
flexible  and  powerful. 

Of  course,  in  composing  the  actual  meta  proof  supplied  to  the  new  SUBT  and  IN¬ 
STR  rules,  it  is  most  likely  that  those  disappeared  lemmas  will  still  be  used.  Nevertheless, 
making  them  separate  from  the  type  language  and  its  meta  theory  is  important  because 
it  reduces  the  size  of  the  type  language,  while  allowing  more  flexible  reasoning.  By  intro- 
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ducing  meta  implication  into  TAL,  we  made  one  step  forward  so  now  there  is  a  mixture 
of  syntactic  types  and  logic  proofs. 

We  call  this  version  of  TAL  a  semantic  TAL  (STAL).  STAL  and  TAL  share  the  exactly 
same  syntax  and  top-level  static  semantics  (Figure  5.2),  as  well  as  the  same  state  and  value 
typing  rules  (Figure  5.4).  While  STAL  has  much  more  reasoning  power  than  TAL  do,  as 
the  soundness  of  STAL  is  simpler  than  TAL's.  Nevertheless,  instead  of  merely  supplying 
type  signatures  to  their  code,  now  the  programmers  have  to  also  supply  meta  logic  proof. 

As  an  intermediate  step  from  TAL  toward  XCAP,  STAL  only  upgrades  TAL's  expres¬ 
siveness  by  using  general  logic  implications  in  the  subtyping  and  instruction  typing  rules. 
STAL  program  specifications  are  still  fully  syntactic  types  and  thus  are  not  as  expressive 
as  general  logic  predicate. 

It  is  obvious  to  obtain  the  following  TAL-to-STAL  typing  translation  theorem.  (We 
ignore  the  trivial  cases  of  those  judgments  where  TAL  and  STAL  share  the  same  rules.) 

Theorem  5.4  (Typing  Preservations  from  TAL  to  STAL) 

L  if  h tal  [A] .  r  <  [A'] .  n  then  hSXAL  [A] .  T  <  [A'] .  T; 

2.  if  V  i  TAL  {r}c{r'}  then  V  f STAL  {r}c{r'}. 

If  we  follow  the  direction  of  STAL  and  make  one  more  step  by  trying  to  bring  in  gen¬ 
eral  logic  predicates  into  the  types,  we  can  obtain  an  even  better  TAL.  In  fact,  XCAP  is 
such  a  system  in  some  sense,  as  the  translation  in  the  next  section  will  show. 

5.4  Translations  from  TAL/STAL  to  XCAP 

The  gap  between  STAL  and  XCAP  is  mainly  on  the  specification  language  and  the  various 
state  and  value  typing.  At  the  core  of  the  translation  from  STAL  to  XCAP  is  the  transla¬ 
tions  from  TAL/STAL  types  and  typings  into  XCAP  predicates,  which  we  discuss  first. 
Our  translations  preserve  the  typing  structure  and  well-formedness  of  TM  programs. 
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Translation  from  TAL  WordTy  to  XCAP  WordTy 
rintn  =  Aw.  True 

rcode  [A].rn  =  Aw.codeptr(w,r[A].rn) 

r(Ti,...,x„)n  =  Aw.record(w,rxr,...,rx„n) 

r3a.xn  =  Aw. 3 a:  Word  — >PropX.r'0  w 
r/ja.xn  =  Aw.  (ju  a:  Word  — >PropX.  'kx'.Word.  (rxn  x)  w) 

Translation  from  TAL  Precondition  to  XCAP  Assertion 

r [oc i , . . . ,  ocm] .  {rj Xi  5 . . . ,  rn x^}-1 

=  A(H,M).  3oq , . . . ,  am  :  Word  —>PropX.  (rXin  M(ri))  A  ...  A  (rx„n  M(r„)) 

Translation  from  TAL  CdHpSpec  to  XCAP  CdHpSpec 

--{l! ^ [Ax ] . Tj , . . . ,  1„ ^ [A„] . r„}^  4  {i1'^r[A1].r1n,...,i„'^r[A„].r,In} 

Translation  from  TAL  DtHpSpec  to  XCAP  DtHpSpec 

r{l[  ^-Xi , . . . ,  1;J'N-^X;J}_1  —  {ll  rXi _l, . . . ,  In rxn_l} 

Figure  5.5:  Translations  from  TAL  types  to  XCAP  predicates 

Translation  of  TAL  types  We  present  the  type  translations  from  TAL/STAL  to  XCAP  in 
Figure  5.5.  Various  r-n  translate  TAL  types  into  XCAP  assertions  and  specifications. 

In  the  word  type  translation,  integer  type  becomes  a  tautology  as  any  machine  word 
can  be  treated  as  an  integer.  Code  type  is  translated  into  ECP  formulas.  Tuple  types  in 
TAL  is  translated  into  record  type  in  XCAP.  Existential  types  and  recursive  types  in  TAL 
are  also  translated  into  their  XCAP  counterparts. 

The  translation  of  a  TAL  precondition,  which  is  a  type  variable  environment  plus  a 
register  file  type,  is  an  XCAP  assertion.  The  type  variables  in  the  environment  are  now 
existentially  quantified  over  XCAP  word  types  at  the  outmost  of  the  target  assertion.  The 
register  file  typing  corresponds  to  a  bunch  of  conjunctions  of  register  value  testing. 

The  translations  of  TAL  code  and  data  heap  specifications  are  carried  out  by  simply 
translating  each  element's  type  in  them  into  XCAP  assertions  or  word  types,  and  preserv¬ 
ing  the  partial  mapping. 
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Typing  Preservations  An  important  property  of  the  previous  translations  is  whether 
they  preserve  the  typing  structure  and  well-formedness  of  TM  program  in  XCAP.  This 
breaks  down  to  whether  all  well-formed  TAL/STAL  entities  are  still  well-formed  in  XCAP 
after  the  translations.  As  the  following  typing  preservation  lemma  shows,  all  STAL  typing 
derivations  indeed  get  preserved  in  XCAP  after  the  translations. 

Theorem  5.5  (Typing  Preservations  from  STAL  to  XCAP) 

1.  If  'P  ^stal  { [A] .  T}  P  then  ^  hXCAP  {r[A] .  T”1}  P; 

2.  if  'P  h stal  C :  XP/  then  rxPn  hXCAp  C :  rxP/_l; 

3.  if  'P  bSTAL  {[A] . T}I  then  ^  bXCAP  {-“[A] . T"1} I; 

4.  if  'P  hSTAL  S :  [A] .  T  then  [[ r [A] .  F1  ]] r>pn  S; 

5.  if  'P I  STAL  H :  4>  then  THH  r»Pn  r<l>n  H; 

6.  if  ¥;<&  Fstal  M:r  then  [r[]-Tn  (M,M) ]]r>In 

7.  if  'P;<4>  h stal  w  ■  ^  then  [[  rxn  w  ]] 

8.  if  b stal  [A] . r  <  [A'] . r  then  r[A].Tn  =>  r [A'] . rn; 

9.  if  V I  stal  {r}c{T'}  then  r[A] .  T\  =*  r[A] .  Tn. 

Proof.  We  show  selected  cases  for  (3).  By  induction  over  the  structure  of  VP  PTal  {[A] .T}L 
case  WEAKEN. 

b  [A].r<  [A'].r  'Pb{[A'].r/}i 

xPb{[A].T}I 

By  induction  hypodissertation  it  follows  that  rvPn  bXCAP  {r[A,].Tn}I.  The  following  weak¬ 
ening  lemma  easily  holds  for  XCAP:  "if  xPb{a,}I  and  a  =>■  a'  then  *Pb{a}F'.  By  (8)  it 
follows  that  r[A].rn  =>-  r[A'].Tn.  Thus  it  follows  that  rvPn  bXCAP  { r [A] . Tn}I. 

case  SEQ. 
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b{r}c{rY}  xPb{[A].r/}I  ce{add,addi,mov,  movi,ld,st} 

¥h{[A].r}c;I 

By  induction  hypodissertation  it  follows  that  rvPn  bXCAP  {r[A].rn}I.  By  (9)  it  follows  that 
r[A].rn,i,  =fcr[A].rn.  By  rule  SEQ  it  follows  that  rvPn  hXCAP  {r[A].rn}c;I. 

case  jd. 

fGdom('f')  h  [Aj.r^^f) 

xf/h{[A].r}jd  f 

By  (8)  it  follows  that  r [A] . F-1  =>■  r*P(f)n,  and  then  r[A].W  =>■  r*Pn(f).  By  rule  JD  it  follows 
that  rxPn  b XCap  {r[A]  •  rn}jd  f. 

case  jmp. 

r(r)  =  code  [A'] .V  b  [A] . F  <  [A'] . V 
'P  b{[A].r}jmp  r 

By  translation  it  follows  that  r[A].rn  b(H, M) . cptr(M(r) , r [A'] . F,n) .  By  (8)  it  follows  that 

r[A].rn  =^>  r[A,].rn.  By  rule  JMP  it  follows  that  r*f/_l  bXCAP  {r[A].rn}jmp  r. 

case  movf. 

fedomOF)  'Pb{[A].r{rrf~vcode  'P(f)}}! 

'P  b{[A].r}movi  zd,f,I 

By  induction  hypodissertation  it  follows  that  rvPn  bXCAP  {r [A] .F{ rf/ ^code  vP(f  By 

rule  ECP  and  SEQ  it  follows  that  rvPn  bXCAP  {r[A].rn}movi  r^,f;L  ■ 

5.5  Discussion 

We  discussed  the  relationship  between  TAL  and  XCAP  by  showing  a  translation  from 
TAL  to  XCAP.  However,  it  is  by  no  means  limited  to  the  translation  itself. 

For  example,  one  can  treat  the  translation  as  a  shallow  embeddeding  of  TAL  types  and 
typing  rules  in  XCAP,  which  means  there  is  no  need  to  build  meta  theory  for  TAL  while 
still  letting  the  programmer  work  at  the  TAL  level. 

One  interesting  way  to  view  the  XCAP  system  is  from  TAL  programmer's  perspective. 
When  writing  programs  that  will  interact  with  XCAP  code  that  involve  complex  logical 
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specification  not  expressible  in  TAL,  so  long  as  the  interfaces  abstract  and  hide  that  part  of 
"real"  logical  specification  ( e.g .,  by  using  existential  packages),  and  local  code  behavior  is 
simple  enough  (which  is  usually  the  case),  the  programmers  can  "pretend"  that  they  are 
dealing  with  external  TAL  code  instead  of  XCAP  ones,  by  using  the  macros  and  lemmas 
defined  for  the  translations.  This  lowers  the  requirement  on  programmers,  as  they  do  not 
need  to  learn  XCAP,  even  if  they  are  dealing  with  external  XCAP  code. 
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Chapter  6 


A  Port  to  x86  Machine 


To  demonstrate  the  potential  of  the  XCAP  framework,  we  want  to  use  it  to  reason  about 
realistic  system  code  that  actually  runs  the  x86  machine,  which  is  different  from  and  more 
complex  than  the  RISC -like  target  machine  used  in  previous  chapters.  In  this  chapter,  we 
present  XCAP86,  a  port  of  the  XCAP  framework  on  Mini86,  a  faithful  subset  of  the  x86 
architecture.  XCAP86  and  Mini86  adds  the  support  of  instruction  decoding,  finite  ma¬ 
chine  word,  word-aligned  byte-addressed  memory,  conditional  flags,  built-in  stack  and 
push/ pop  instructions,  and  function  call/ return  instructions. 

The  Mird86  machine  is  realistic,  which  brings  additional  complexities  and  proof  engi¬ 
neering  issues.  Therefore,  on  top  of  XCAP86,  we  made  practical  adaptations  and  built  use¬ 
ful  abstractions,  particularly  on  the  handling  of  the  stack  and  function  calls.  We  demon¬ 
strate  the  usage  of  the  XCAP86  and  these  abstractions  for  the  verification  of  a  polymorphic 
queue  module,  which  is  going  to  be  used  by  the  mini  thread  library  in  the  next  chapter. 

6.1  Mini86:  a  Subset  of  the  x86  Architecture 

The  execution  environment  of  Mini86  (Figure  6.1)  consists  of  a  memory,  a  register  file  of 
eight  general-purpose  registers,  a  flags  register  made  up  of  a  carry  bit  and  a  zero  bit,  and 
a  program  counter.  Following  the  x86  Flat  Model  [34],  the  memory  of  Mini86  appears 
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pc 


F  cf  zf 

R 


eax 

esi 

ebx 

edi 

ecx 

ebp 

edx 

esp 

Code 


Static 


Heap 


unavailable 


Stack 


H 

■4 — hp_start 


4 — system  break 


4 — ss_start 


4 — ss_end 


Figure  6.1:  Mini86  execution  environment 


to  a  program  as  a  single,  continuous  address  space.  Code,  data  (static  and  dynamic),  and 
system  stack  all  reside  in  this  address  space.  Mini86  has  a  word  size  of  32  bits.  Its  memory 
is  finite  and  ultimately  restricted  by  the  word  size.  The  non-code  part  of  the  memory,  the 
register  file,  and  the  flags  register  are  referred  to  collectively  as  the  machine  state. 

In  comparison,  the  actual  x86  execution  environment  uses  an  EFLAGS  register  to  record 
a  group  of  status  and  control  flags  including  those  mentioned  above,  and  the  eip  (pro¬ 
grammer  counter)  register  can  also  be  controlled  implicitly  by  interrupts  and  exceptions, 
which  we  omit.  We  also  omit  the  segment  registers  in  x86,  because  they  play  no  role  in 
the  Flat  memory  model. 

The  syntax  of  Mini86  is  shown  in  Figure  6.2.  In  Mini86,  two  memory  addressing 
modes  are  supported:  a  "direct"  mode  uses  an  immediate  value  as  the  absolute  address;  a 
"base  indexed"  mode  uses  a  register  value  as  the  base  address  and  an  immediate  value  as 
the  offset.  Common  instructions  are  included  for  arithmetic,  data  movement,  comparison, 
control  flow  transfer,  and  stack  manipulation. 

An  operand  (o)  is  either  an  immediate  value  or  a  register.  When  an  instruction  takes 
two  operands,  the  first  one  is  the  target  operand.  Conditional  jumps  are  supported  with 
help  of  conditional  codes  (a,  b,  and  e  stands  for  above,  below,  and  equal  respectively),  which 
are  represented  by  different  combinations  of  cf  and  zf,  and  set  by  arithmetic  and  compari¬ 
son  instructions. 

We  present  the  operational  semantics  of  Mini86  in  Figure  6.3.  All  instructions  are 
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(Program)  P  ::=  (§,pc) 

(State)  §  ::=  (H,R,F) 

(Mem)  H  ::=  {l^-w}* 

(Rfile)  M  ::={r'^-w}* 

(FReg)  P  ::=  {cf  ^  b,  zf  ^  b} 

(Word)  w  ::=  i  (unsigned  32  bit  integers) 

(Labels)  1  ::=  i  (unsigned  32  bit  integers,  i%4  =  0) 

(CdLbl)  f  ::=  i  (unsigned  32  bit  integers) 

(Reg)  r  ::=  eax  |  ebx  |  ecx  |  edx  |  esi  |  edi  |  ebp  |  esp 
(Bool)  b  ::=tt  \  ff 
(Cond)  cc  ::=  a  |  ae  |  b  j  be  |  e  |  ne 
(Addr)  d  ::=  i  |  r ±/‘ 

(Opr)  o  ::=  i  \  r 

(Instr)  c  ::=  add  r,o  |  sub  r,o  |  mov  r,o  |  mov  r,  [d]  |  mov  [d],o 

|  cmp  r,  o  |  \cc  f  j  jmp  o  j  push  o  j  pop  r  |  pop  |  call  o  |  ret 

Figure  6.2:  Mini86  syntax 


encoded  as  machine  words  and  stored  in  the  memory;  at  each  step,  the  machine  has  to 
decode  the  instruction  from  the  memory  at  pc.  During  execution,  the  machine  would 
fetch  words  based  on  the  program  counter  pc  and  decode  the  words  before  executing  it. 

We  use  Dc  to  fetch  and  decode  an  instruction  out  of  the  memory  H  given  a  program 
counter  pc.  The  result  of  Dc  is  an  instruction  c  and  a  new  program  counter  npc.  We 
also  use  a  macro  Nextc(S)  to  define  the  transition  of  the  machine  state  on  some  of  the 
instructions.  It  is  worth  noting  that  this  macro  provides  only  a  partial  mapping:  there  are 
cases  where  no  valid  next  states  are  defined.  Examples  include  accessing  invalid  memory 
or  stack  locations.  The  Mini86  machine  gets  stuck  in  these  cases. 

The  stack  instructions  of  Mini86  assume  that  the  stack  pointer  is  held  by  esp.  As  a 
general  rule,  esp  should  not  be  used  for  any  other  purposes.  For  example,  the  push  o 
instruction  decrements  esp  by  4  and  writes  the  value  of  o  onto  the  new  top  of  the  stack. 
The  pop  r  instruction  reads  a  value  from  the  top  of  the  stack,  puts  it  into  r,  and  increments 
esp  by  4. 
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Suppose  Dc(M,  pc)  =  (c,npc) 

if  c  = 

then  ((H,R,F),pc)  i — * 

jmp  o 

(H,R)R(o) 

jcc  f 

if  F(cc)  then  (H,R)f  else  (HI,R)npc 

where  suppose  F=  {cf  ^  cf,  zf  ^  zf},  we  have 
F(a)  =  -ic/A-iz/,  F(ae)  =-ic/,  F(b )  =  cf, 

F  (be)4c/Vz/,  ¥(e)=zf,  F(n  e)4-,z/ 

call  o 

(NextpUsh  „pc(EI,R,F),R(o)) 

ret 

(Nextpop(IHI,R,F),]HI(sp))  when  sp  edom(HI) 

c 

(Nextc(EI,R,F),npc) 

where 


if  c  = 

then  Nextc(BI,R,F)  = 

add  r,  o 

(H,R{r^R(r)+R(o)},CalcF(R(r)+R(o))) 
when  0<R(r)+R(o)  <232 

sub  r,  o 

(H,R{r^R(r)— R(o)},CalcF(R(r)— R(o))) 
when  0  <  R(r)  — R(o)  <  232 

cmp  r,  o 

(H,R,CalcF(R(r)— R(o))) 

mov  r,o 

(H,R{r~»R(o)},F) 

mov  r,  [d] 

(EI,R{r~»EI(R(d))},F)  when  R(d)  edom(HI) 

mov  [d] ,  o 

(BI{M(d)~>M(o)},R,F)  when  R(d)  Sdom(H) 

push  o 

(H{sp— 4~>M(o)},  R{esp~>sp— 4},F) 
when  sp— 4e  dom(H) 

pop  r 

(H,R{r^H(sp)}{esp~i-.s'p+4},  F) 
when  sp  edom(HI)  and  0<sp+4<232 

pop 

(H,R{esp-^sp+4},  F) 
when  0  <  sp+ 4  <  232 

Dc()  is  the  instruction  decoding  function 

R(i)  =  i  R(r)  =  R(r)  R(r±i)=R(r)±i 

CalcF(i)  =  {cf  i— > ;  <  0.  zf  i— > ;  =  0} 

Figure  6.3:  Dynamic  semantics  of  Mini86 
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The  call  instruction  pushes  the  return  address  (calculated  from  pc)  onto  the  stack  and 
transfers  the  control  to  the  callee  (by  updating  pc).  The  ret  instruction  bump  the  stack 
pointer  by  4  and  transfer  the  control  to  the  return  address.  Note  that  the  ret  instruction 
does  not  necessarily  transfer  the  control  back  to  the  caller,  as  the  program  may  modify 
the  stack  in  arbitrary  ways.  Such  maneuver  is  indeed  commonly  used  in  implementing 
thread  primitives. 

6.2  XCAP86:  a  Port  of  XCAP  on  Mini86 

In  this  section  we  first  introduce  the  XCAP86  language,  where  most  of  the  constructs  and 
rules  are  the  same  as  XCAP.  We  then  discuss  how  to  abstract  and  reason  about  memory, 
stack,  function  call/ return  interfaces. 

Assertion  language.  The  syntax  of  XCAP86  is  given  in  Figure  6.4.  We  abstract  a  code 
heap  C  out  of  the  actual  memory  H  of  Mini86.  Although  the  code  heap  is  presented  in  the 
syntax  as  a  mapping  from  code  labels  to  instruction  sequences,  it  is  actually  embedded  in 
the  memory  by  encoding  instructions  as  machine  words.  XCAP86  includes  features  such 
as  embedded  code  pointers,  impredicative  polymorphisms,  and  recursive  specifications. 

We  present  the  validity  rules  of  XCAP86  extended  propositions  in  Figure  6.5.  Follow¬ 
ing  XCAP,  the  interpretation  of  extended  propositions  is  defined  as  their  validity  under 
the  empty  environment: 

[[P]]«r  =  •  hp  P 

Following  XCAP,  we  establish  the  following  soundness  theorem  of  the  interpretation 
of  extended  propositions  (with  respect  to  CiC/  Coq). 

Theorem  6.1  (Soundness  of  XCAP86  PropX  Interpretation) 

1-  If  tt(p>I<*>  then/?; 

2.  if  Jcptr(f  ,a)JVI,  then 'P(f)  =  a; 
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(' CodeHeap )  C 

(. InstrSeq )  I 

(. PropX )  P,  Q 


(' CdHpSpec ) 


::={f  ^1}’ 
::=  c  |  c;[f 
::=  (p) 

cptr(f ,  a' 
PAQ 
P¥Q 
P-^Q 
y/x-.A.  P 
3jc:A.P 


c;I 


lifted  meta  proposition 
embedded  code  pointer 
con  junction 
disjunction 
implication 
universal  quant ificat ion 
existential  quantification 
Va :A  — >  PropX.  P  imp.  universal  quan. 
3a:A  — >  PropX.  P  imp.  existential  quan. 
(ji  a.  Ajc  : A .  P  B)  recursive  definition 

::={f^a}* 


(. Assertion )  a  e  State  — >  PropX 

( Assertlmp )  a=^a'  =  V'FjS.  [a]]^  §  D  [a7]^  § 
(Steplmp)  a  a'  =  V'FjS.  [[ a]]^  §  D  [[a']]^  Nextc(§) 


Figure  6.4:  Syntax  of  XCAP86 
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F  P  (Validity  of  Extended  Propositions)  (env)  F  :  =  •  |  F,  P 

(The  following  presentation  omits  the  'F  in  judgment  T  h»j<  P.) 


per 


(env) 


rhp 

'P(f)  =  a 
rhcptr(f,a) 


((H) 


(CP-I) 


ri-<p) 

n-cptr(f,a) 


rh(p)  pp(rhg) 

rhq 

mf)  =  a)D(rhQ) 


rhq 


(0-h) 

(CP-E) 


rpp  rhq,A_rt 

rhPAQ 

( A-El) 

rhPAQ 

( A-E2) 

rhPAQ 

rhp 

rhq 

rhp  (V-Il) 

rhq 

( V-l2) 

rhpvq 

r,phR 

FQhR 

rhpvq (  ’ 

rhpvq 

rhR 

r,P  hQ 


(— I) 


B:A 


rhp^Q 

r  hP[fi/jc]  VB:A 
r  hW*  :A.  P 

rhP[B/x] 


rhp^Q  rhp 
rhq 

ThWjciA.P 


(->-E) 

B:A 


(ill) 


Th3i:A.P 


ThP  [B/x] 
r,P [B/x]  hQ 


VB\A 


ThlrA.P 
rhP[a/(x]  Va  :A—>PropX 


rhq 

a  :A— >PropX 


rhP[a/a] 


T\-Va:A^PropX.P  T\-3a:A^PropX.P 

B:A  Th  P[B/x\[pa:A  — >  PropX.hc:A.P/a ] 


(3-El) 


(3-12) 


Th  (/i  a: A— >PropX.hc:A.P  B) 


Oi-I) 


Figure  6.5:  Validity  rules  of  XCAP86  extended  propositions 
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3.  if  [[PAQflvp  then  [[P]]¥  and  [[Qj^; 

4.  if  [PVQ]]q,  then  either  [[P]]>j,  or  [Q  ]],*,; 

5.  if  [P— and  [[Pj^  then 

6.  if  J¥^:A.P]]vj,  and  B:A  then  [[PfS/jc]]]^; 

7.  if[3jc:A.P]]q,  then  there  exists  B :  A  such  that  [  P  [B/x]  ]]  vj,; 

8.  if  j¥a:A— ►PropX.P]]1I,  and  a:A^PropX  then  fP[a/a]]]¥; 

9.  if  J3a:A  — >PropX.  P]]^,  then  there  exists  a:  A  —tPropX  such  that  [[P[a/a] ]],F; 

10.  if  [[(ju  oc.Ajc:A.P  B)]]^  then  [[P[S/jc][(/i  a.Ut:A.P  )/a]]]1I,. 

Corollary  6.2  (XCAP86  Consistency)  [[  (False)  is  not  provable. 

Inference  rules.  The  major  difference  between  XCAP86  and  XCAP  is  on  the  inference 
rules,  which  is  presented  in  Figure  6.6.  In  the  top-level  well-formed  program  rule,  DC(C) 
is  a  predicate  that  establishes  the  proper  instruction  decoding  relation  between  the  code 
heap  C  and  the  memory  EL  Its  implementation  makes  use  of  the  single-instruction  de¬ 
coding  function  Dc()  that  appears  in  the  previous  section.  lookup(C,f  ,1)  is  a  macro  that 
checks  whether  the  instruction  sequence  I  is  inside  code  heap  C  at  location  f . 

Using  cptr,  XCAP86  supports  the  reasoning  of  embedded  code  pointers  (ECP)  in  gen¬ 
eral.  The  idea  can  be  naturally  adapted  according  to  the  x86  additional  instructions  that 
use  ECPs.  In  particular,  there  are  now  three  new  rules  for  the  function  call  and  return  in¬ 
structions  of  Mini86,  assuming  a  built-in  stack.  A  call  instruction  pushes  a  return  address 
onto  the  stack  and  transfers  the  control  to  the  target  code.  In  our  actual  implementation, 
the  return  address  is  calculated  from  the  pc.  To  avoid  obfuscating  the  presentation,  we 
used  an  explicit  [f  ret\  in  the  above  Rule  CALLI.  This  rule  says,  if  a  holds  on  the  current 
state,  then  *P(f )  holds  on  the  updated  state  after  executing  the  stack  push.  The  Rule  RET 
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^0h{a}P 


(Well-formed  Program ) 


^GhC:^G 


((DC(C)  *  [[ a ]] vj,  )  S)  lookup(C,pc,I) 
^G  h{a}  (§,pc) 


*¥-  hjajl 
— - -  (PROG) 


'P;v  F  C :  'P  (Well-formed  Code  Heap) 

^(-{a/H-  Vff 


^  I"  {f  :  {f  1  ~>ai, . . .  ,f„^a„} 


(CDHP) 


F  Ci  i'Pi  ^IN2  F  C2  :^2  ^wl(f )  =  'P/W2(f ) 
dom(Ci)ndom(C2)  =0  Vf  Gdom('P/A,1)ndom('P,A,2) 
'P/jv1U'Pw2FC1UC2:'PiU'P2 


(link) 


PI-{a}I  (Well-formed  Instruction  Sequence) 


a  =>c  a7  'PFja7}!  cejadd,  sub,  cmp,mov,  push,  pop} 


¥h{a}c;I 

a^'P(f)  f  edom('P) 
*Fh{a}jmp  f 


(SEQ) 


(jMPl) 


(X(H,R,F).(-.F (cc))  A  a  (H,M,F))  =>■  a7  Ph{a'}I 
(X(H,M,F).  (F(cc))  A  a  (H,M,F))  =>  »P(f )  f  G  dom(^) 


*P  F  {a}jcc  f ;I 
a  =>■  X(H,M,F).  cptr(M(r),a7) 


(JCC) 


a  =>■  a 


(jmpr) 


*P  F{a}jmp  r 

(AS.cptr(f,'P(f))AaS)  =^a7  fGdom(^)  Ph{a'}I 


^push 


Ph{a}I 

fre(^(f)  f€domW 


(ecp) 


'PI- {a} call  f ; [f ,-ef] 
a  =>-  X(H,  M,  F) .  cptr(M(r) ,  a7) 


(CALLI) 


^push  f 


'Ph  {a}  call  r;[f  ret] 
a  =>-  X(H,M,F).cptr(BI(M(esp)),a/)  a  =^,op  a7 


¥  F  {a}  ret 


(callr) 

(ret) 


Figure  6.6:  Inference  rules  of  XCAP86 
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says,  the  top  of  the  stack  is  a  code  pointer  with  pre-condition  a7  and,  if  a  holds  on  the 
current  state,  a7  holds  on  the  updated  state  after  popping  out  the  return  address. 

It  is  worth  noting  that  Rule  CALLI  does  not  enforce  the  validity  of  the  return  address. 
This  allows  some  "fake"  function  calls  that  never  return,  a  pattern  indeed  used  in  the 
thread  library  in  the  next  chapter.  Specialized  derived  rules  can  be  built  as  lemmas  to 
reflect  regular  function  calls. 

Soundness.  Following  XCAP,  we  establish  the  soundness  of  these  inferences  rules  with 
respect  to  the  Mini86  operational  semantics. 

Lemma  6.3  (XCAP86  Progress) 

If  'Pg  F  {a}  P,  then  there  exists  a  program  P7  such  that  P  i — >  P7. 

Lemma  6.4  (XCAP86  Preservation) 

If  'Pg  F  {a}  P  and  P  i — >  P7  then  there  exists  an  assertion  a7  such  that  XPG  b  {a7}  P7. 

Theorem  6.5  (XCAP86  Soundness) 

If  VPG  h  {a}  P,  then  for  all  natural  number  n,  there  exists  a  program  P7  such  that  Pi — >n  P7. 

For  the  presentation  of  the  rest  of  this  chapter  and  the  next  chapter,  we  ignore  the 
difference  between  Prop  and  PropX,  and  always  use  the  syntax  of  Prop  terms  for  PropX 
terms  and  p  for  p. 

Reasoning  about  memory.  The  reasoning  on  memory  (data  heap  and  stack)  operations 
is  largely  carried  out  following  separation  logic  [48,  53].  In  particular,  the  primitives  of 
separation  logic  are  defined  as  shorthands  using  the  primitives  of  the  underlying  logic  in 
XCAP  (a  shallow  embedding  of  separation  logic  in  the  assertion  language).  Some  repre¬ 
sentative  cases  are  given  as  follows. 
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emp  =  XH.H={} 

1 ! — >  w  =  A,H.l^NULLABI={l'^>w} 

1i— >_  =  XH.  3w.  (li— >  w  H) 
ai  *  a2  —  XH.  3Hi , H2. Hi  WBI2  =  H  A  ai  Hi  A  a2  H2 
li— >  wi, . . . ,  w„  =  1 1 — >  Wi  *  l+4i— >W2  *  ...  *  l+4(n  — 1)  1— >w„ 

1 ! — >  [w]  =  1 1 — >  (the  number  of  _  isn/4) 

emp  asserts  that  the  memory  is  empty,  li— >w  asserts  that  the  memory  contains  exactly 
one  word  at  address  1  with  the  value  w;  when  the  value  is  not  important,  a  wildcard 
is  used  as  in  1 1— >  _.  Separating  conjunction  a  *  a7  asserts  that  the  memory  can  be  split 
into  two  disjoint  parts  in  which  a  and  a7  hold  respectively  (l±l  represents  disjoint  union), 
li— ►  wi, . . . , w„  asserts  that  1  is  the  starting  address  of  a  sequence  of  words  wi , . . . , w„;  our 
memory  is  addressed  by  bytes,  hence  the  number  4  (one  word  is  4  bytes).  Finally,  li— >•  [n] 
means  that  1  points  to  n  bytes.  For  conciseness,  we  sometimes  omit  lambda  and  existential 
bindings  of  variables,  thus  writing  Xri , . . .  ,xn.  3yi , . . .  ,ym.  P  simply  as  P  when  there  is  no 
confusion.  We  also  sometimes  simplify  (a*  a7  H)  as  a*  a7. 

Stack  and  calling  convention.  Besides  specializing  XCAP  for  our  machine  model,  we 
also  built  key  abstractions  to  help  manage  the  complexity  of  the  reasoning,  such  as  the 
handling  of  the  stack  and  calling  convention. 

Most  Mini86  code  follows  the  convention  illustrated  in  Figure  6.7.  The  return  address 
is  on  stack  top  [esp] .  Function  arguments  follow  in  [esp  +  4] ,  [esp  +  8] ,  etc. .  The  return  value 
is  stored  in  eax.  Unless  specified  otherwise,  ebx,esi,edi  and  ebp  are  callee-save  registers. 

It  is  therefore  convenient  to  built  a  specification  template  reflecting  this  convention. 
For  a  function  with  n  arguments  a\  . . .  an,  we  write  its  specification  (i.e.,  a  pre-condition  in 
the  form  of  an  assertion)  as: 

Fn  ci\ , . . . , {Aux  .  x\ , . . . , xm,  Local .  [f 5  Pre  .  B.pre,  Post . 

The  intention  of  this  macro  is  that  x\, . . .  ,xm  are  "auxiliary  variables"  commonly  used  in 
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Figure  6.7:  Function  calling  convention 

Hoare-logic  style  reasoning,  fs  is  the  size  of  required  free  space  on  the  stack,  and  apre  and 
a pOSt  are  the  pre-  and  post-conditions  of  the  function.  We  sometimes  refer  to  the  variables 
collectively  as  a  and  x.  This  macro  is  defined  as  follows: 

dftj,  .  .  .  ,Gn,CS ,  Sp ,  SS  ,7  Ct  .  .  .  ,  Xmi  &-prv‘ 

reg(cs,sp)  A  ss>fs 

A  S\ack(sp,ss,ret,ai, . . .  ,an)  *  apn,  *  apre 
A  cptr (ret,  Bretv.  reg(cs,sp+4)  Aeax  =  retv 

A  stack(5p+4,55+4,ai,...,a„)  *  aprv  *  apost) 

The  first  line  of  this  definition  quantifies  over  the  values  of  (1)  function  arguments 
ai,..., cin,  (2)  callee-save  registers  cs  (a  4-tuple),  (3)  the  stack  pointer  sp,  (4)  the  size  of 
available  space  on  stack  ss,  (5)  the  return  address  ret,  (6)  auxiliary  variables  x\ , . . .  ,xm,  and 
(7)  some  hidden  private  data  expressed  as  the  predicate  apn,. 

The  second  line  relates  the  register  file  with  the  callee-save  values  cs  (4-tuple)  and  the 
stack  pointer  sp  using  the  macro  below.  It  also  makes  sure  that  there  is  enough  space 
available  on  the  stack. 

reg  ( ebx ,  esi,edi,  ebp,esp)  =  ebx  =  ebx  A  esi  =  esi  A  edi  =  edi  A  ebp  =  ebp  A  esp  =  esp 

The  third  line  describes  (1)  the  stack  frame  upon  entering  the  function  using  the  macro 
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below,  (2)  the  private  data  hidden  from  the  function,  and  (3)  the  user  customized  pre¬ 
condition  apre,  which  does  not  directly  talk  about  register  files  and  the  current  stack  frame, 
since  they  have  already  been  handled  by  the  calling  convention. 


stacW(sp,ss,wi, . . .  ,wn)  —  sp— ss>— >[55]  *  sp^w  1, _ ,w„. 


The  last  two  lines  of  the  Fn  definition  specify  the  return  address  ret  as  an  embedded 
code  pointer  using  cptr.  When  a  function  returns,  the  callee-save  registers,  stack  frame, 
and  private  data  must  all  be  preserved,  and  the  post-condition  apost  must  be  established. 
Note  that  (1)  eax  may  contain  a  return  value  retv,  and  (2)  the  return  instruction  automati¬ 
cally  increases  the  stack  pointer  by  4. 

We  built  another  abstractions  to  help  manage  the  complexity  of  verification.  It  is  a 
finer-grained  version  of  Fn  which,  besides  following  the  convention  above,  also  specifies 
local  variables  on  the  stack  by  extending  the  "Local :  [fs] part  to  "Local  :  [fs] ,  vi , . . . ,  v*;", 
where  v,-  are  the  local  values  on  the  stack.  The  definition  of  this  new  Fn  is: 


3«i ;  •  •  •  j  fln  j  v  1  sp,ss,  ret  ,xi , . . .  ,xm,  a.prv. 

reg(cs,sp)  A  ss>fs 

A  slacW(sp,ss,v\, . . .  ,vk,ret,cii, . . .  ,an)  *  apn,  *  apre 
A  cptr  (ret,  3  retv.  reg(cs,sp+4)  Aeax  =  retv 

A  s\ack(sp+4+4k,ss+4+4k,ai, . . .  ,an)  *  aprv  *  apost) 

We  define  many  derived  rules  (implemented  as  lemmas)  to  facilitate  the  reasoning  related 
to  functions  specified  using  the  new  Fn.  We  provide  the  following  examples: 
apre  =>c  a  T1  h{Fn  a  {Aux:T; Local:  [fs] , v; Pre : a; Post : apost}}I 


'T  b{Fn  a  {Aux:T; Local :  [fs |,v;  Pre:  apre; Post:  apost}}  c;I 


(FN-SEQ) 


fs> 4  T1  h{Fn  a  {Aux:T: Local :  [fs— 4] , w,  v;Pre:  apre\  Post  :ap0i,}}I 

T1  h{Fn  a  {Aux \x\ Local :  [fs], v; Pre :apre; Post :ap0iS/}} push  w;I 


(FN-PUSH) 
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\P(f)  =  Fn  a'  {Aux:x/;  Local:  [/.s,];Pre:apW';Post:a/WJf/} 
i^-ret)  —  Fn  a  ^ Aux . x ,  Local .  \f  s]  5  v,  Pro .  a,  Post  •  &  post } 

3-pre  ^  (aprv  *  apre  A  (a.prv  *  &post  ^  a)) 

fs-4>fs’  fedomQF)  f^edomQF) _  (fn-calli) 

xFh{Fn  a  {Aux:v;  Local:  [fs], v;Pre:apre; Post :apoi(}} call  f;[f ret\ 

3-pre  '  3-poi/  .  . 

'P  h  {Fn  a  {Aux  :*;  Local :  [/s] ;  Pre :  apre;  Post :  ap01f }}  ret  v 

6.3  Verification  of  a  polymorphic  queue  module 

We  demonstrate  some  of  those  macros  defined  in  the  previous  section  with  the  specifica¬ 
tion  and  verification  of  a  polymorphic  queue  module,  which  will  be  used  by  the  thread 
library  in  the  next  chapter.  Our  queue  module's  C  specification  as  follows. 

typedef  struct  node_st  *node_t; 
struct  node_st  node_t  next; 

void  queue_insert  (node_t  *q,  node_t  t) ; 
node_t  queue_delete  (node_t  *q) ; 

The  modules  defines  a  node  data  structure  and  functions  for  queue  insertion  and  remove. 
We  define  the  XCAP86  data  type  for  the  queue  noder  pointer  as  follows: 

node_t_ref(a,nil,g)  =  gi-^NULL 

node_t_ref(a,f ::tl,q)  =  q^t  *  a(f)  *  node_t_ref(a,t/,t) 

This  defines  a  data  structure  of  polymorphic  queues,  where  the  link  field  of  a  queue  node 
is  always  stored  in  the  first  word  of  the  node.  More  specifically,  node  t  reffa.  \t].q)  repre¬ 
sents  that  q  is  a  pointer  to  a  queue;  the  locations  of  the  queue  nodes  are  collected  as  a  list 
[t\,  and  every  queue  node  satisfies  the  predicate  a.  The  definition  is  inductive.  In  the  base 
case,  an  empty  queue  specifies  just  the  queue  pointer  q  itself,  which  points  to  NULL.  In 
the  inductive  case,  a  queue  comprises  of  a  head  node  at  t  satisfying  a  and  a  tail  queue  of 

node_t_ref(a,t/,0- 
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queue  .insert  will  insert  a  properly  shaped  node  into  the  end  of  the  queue,  queue  .d  el  ete() 
returns  NULL  when  the  queue  is  empty,  otherwise,  it  returns  the  first  node  of  the  queue 
and  removes  it  from  the  queue.  We  present  the  code  and  verification  of  queue  .insert  () 
and  queue _d el ete()  in  Figure  6.8  and  Figure  6.9.  In  the  figures,  there  are  assembly  code, 
comments,  function  interfaces,  and  assertions  at  each  key  program  point. 

As  the  next  chapter  will  show,  the  polymorphic  queue  module  can  be  used  by  multiple 
modules,  which  demonstrates  the  modularity  of  its  specifications. 
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Fn  q,t  {  Aux:  a ,fZ;  Local:  [0] 

Pre:  node_t_ref(a,t/,^)  a  f, 

Post:  node_t_ref (a,  tl @  [f] ,  q) } 

queue_insert:  // void  queue -insert  (node_t  *q,  node_t  t); 

Local:  [0];  Pre:  node_t_ref(a,  fZ,g)  *fi— >_*a(f) 

mov  ecx,  [esp+4] 
mov  edx,  [esp+8] 

mov  [edx+_next]  ,  NULL  //  t->next  =  NULL; 
mov  eax,  [ecx]  //node_tp  =  *q; 

Local:  [0];  Pre:  node_t_ref(a,?Z,g)  *  node_t_ref(a,  [],f)  *  a  t  Aeax  =  head(iZ)  A  ecx  =  <7  Aedx  =  ? 

cmp  eax ,  NULL  //  if  (p  --  NULL)  //  add  as  first  element 

jne  qi_els 

Local:  [0];  Pre:  node_t_ref(a,rZ,g)  *  node_t_ref(a,  [], f)  *  a  t 

Aeax  =  head(fZ)  =  N  ULL  A  ecx  =  q  A  edx  =  t 

//  unfold,  cast 

Local:  [0];  Pre:  a  t  *  node_t_ref(a,  [],z)  Aecx  =  g  Aedx  =  r  AZ/  =  [] 

mov  [ecx],  edx  //*q  —  t; 

Local:  [0];  Pre:  q^t  *  a  t  *  node_t_ref(a,  [],f)  Aecx  =  q  Aedx  =  f  AfZ  =  [] 

H fold,  cast 

Local:  [0];  Pre:  node_t_ref(a,rZ@[f],g) 

ret  //  return; 

qi_els: 

Local:  [0];  Pre:  node_t_ref(a, fZ,g)  *  node_t_ref(a,  [], f)  *  a  t 

Aeax  =  head(zZ)  /NULL  Aecx  =  gAedx  =  r 

//  cast 

Local:  [0];  Pre:  node_t_ref(a, fZ,g)  *  node_t_ref(a,  [], f)  *  a  t 

Aeax  =  last (zZl)  Aedx  =  r  Atl  =  tll@tl2 

mov  ecx ,  eax  //  while  (p->next !—  NULL)  // insert  at  the  tail 

mov  eax,  [eax+_next]  //p  =  p->next; 

Local:  [0];  Pre:  node_t_ref(a, fZ,g)  *  node_t_ref(a,  [], f)  *  a  t 

Aeax  =  head (zZ2)  Aecx  =  last(zZl)  Aedx  =  r  Atl  =  tll@t!2 

cmp  eax,  NULL 
jne  qi_els 

Local:  [0];  Pre:  node_t_ref(a, fZ, g)  *  node_Lref (a,  [],/*  a  r 

Aeax  =  head  (zZ2)  =  NULL  A  ecx  =  Iast(z7 1 )  A  edx  =  t  Atl  =  tll@tl2 

//  cast 

Local:  [0];  Pre:  node_t_ref(a,rZ,g)  *  node_t_ref(a,  [], f)  *  a  t  Aecx  =  last(zZ)  Aedx  =  f 

mov  [ecx+_next]  ,  edx  // p->next  =  t; 

Local:  [0];  Pre:  node_t_ref(a,fZ@[f],g) 

ret  //  return; 


Figure  6.8:  Verificatgyi  of  queue  insertion 


mov  ecx,  [esp+4] 

mov  eax,  [ecx]  // node_t  t  —  *c\; 


Local:  [0];  Pre:  node_t_ref(a,?/,g)  A  eax  =  head (7/)  /\ecx  =  q 


cmp  eax,  NULL  // if  (t  !=  NULL) 

je  qcLret 


mov  edx,  [eax+_next]  // *q  =  t->next; 
mov  [ecx] ,  edx 


Local:  [0];  Pre:  t  >— >_*  a  r  *  node_t_ref(a,rZ',^)  Aeax  =  r  A  eax /NULL  Atl =t:tl' 
ret  //  return  t ; 


qd_ret: 

Local:  [0];  Pre:  node_t_ref(a, ?/,<?)  Aeax  =  head(i/)  A  ecx  =  g  A  eax  =  NULL 
ret  //  return  t; 

Figure  6.9:  Verification  of  queue  deletion 
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Chapter  7 


A  Certified  Mini  Thread  Library 


In  this  chapter,  we  describe  the  mechanized  verification  of  a  thread  implementation  at  ma¬ 
chine  level  using  XCAP86.  Using  the  first  mechanized  proof  for  the  safety  of  a  machine- 
level  thread  implementation,  we  want  to  demonstrate  the  power  and  practicality  of  the 
XCAP  framework,  and  that  the  certification  of  complex  machine-level  system  code  is  not 
beyond  reach.  Our  mini  thread  library,  MTH,  written  in  Mini86,  is  divided  into  mod¬ 
ules  for  polymorphic  queue  (presented  in  the  previous  chapter),  memory  management, 
machine  context,  and  threading. 

All  MTH  code  are  at  the  same  realistic  level  as  the  context  switching  example,  follow¬ 
ing  the  Windows /Unix  style.  MTH  and  its  verification  involve  neither  change  of  system 
programming  style  nor  disposal  of  existing  system  code  base.  There  is  no  performance 
penalty,  nor  is  any  compatibility  issue. 

The  specifications  and  proof  of  MTH  modules  and  routines  are  modular.  Each  piece 
of  code  is  specified  and  proved  with  minimal  reference  to  external  code.  For  example,  in 
the  verification  of  context  module,  there  is  no  mentioning  of  thread  at  all. 

We  first  give  an  overview  of  MTH  structure,  threading  model,  and  threading  features. 
Then  we  present  the  verifications  of  the  machine  context  module  and  the  threading  mod¬ 
ule  independently. 
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7.1  MTH:  A  Mini  Thread  Library 


MTH  is  a  minimal  thread  library  initially  modeled  after  the  GNU  Portable  Threads  (Pth)  [17]. 
,  a  portable  POSIX/ ANSI-C  based  library  for  Unix.  MTH  supports  non-preemptive  schedul¬ 
ing  for  cooperative  multi-threading.  While  sharing  the  same  address  space,  every  thread 
has  its  own  program  counter,  register  set,  and  stack.  For  simplicity,  MTH  omits  some 
advanced  features  from  Pth,  including  priority-based  scheduling  and  events  and  sig¬ 
nals,  and  adopts  some  small  changes  in  the  library  structures.  Nonetheless,  the  handling 
of  machine  contexts  and  thread  management  reflects  sophisticated  invariants  of  multi¬ 
threading  and  suffices  in  demonstrating  the  difficulty  of  verifying  machine-level  thread 
implementation. 

MTH  structures.  Figure  7.1  divides  MTH  into  several  modules.  Thread  primitives  visi¬ 
ble  to  the  user  are  implemented  in  the  threading  module,  which  refers  to  three  other  mod¬ 
ules:  machine  context,  memory  and  queue.  The  queue  module  is  the  one  discussed  in  the 
previous  chapter.  Pseudo-code  interfaces  of  these  modules  are  provided  for  the  ease  of 
understanding.  In  later  sections,  we  will  develop  more  accurate  specifications  for  verifi¬ 
cation  purposes. 

The  memory  module  is  a  miniature  library  for  dynamic  storage  allocation.  It  provides 
routines  for  heap  allocation  and  deallocation.  The  queue  module  supports  insertion  and 
removal  of  queue  elements  in  the  expected  way.  Its  routines  are  polymorphic  and  can  be 
applied  to  different  types  of  queues,  as  long  as  every  queue  element  stores  its  link  pointer 
in  its  first  word. 

The  machine  context  module  deserves  some  attention.  A  machine  context  (type  mctx  st) 
stores  the  values  of  general-purpose  registers,  where  the  stack  pointer  esp  should  point 
to  a  stack  with  a  valid  return  address  on  top.  Context  switching  swapcontextQ  saves 
the  current  context  as  old,  and  loads  a  new  one  from  new  for  further  execution.  Context 
loading  loadcontextQ  loads  a  new  context  and  executes  from  there.  Context  creation 
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queue  module 

typedef  struct  node_st  *node_t; 
struct  node_st  {node_t  next}; 
void  queuejnsert  (node_t  *q,  node_t  t); 
node t  queue delete  (node t  *q); 


_ t _ 

(  memory  module  ^ 

void  *flist=  NULL; 
void  *malloc  (int  size); 
vvoid  free  (void  *ptr); 


f _ threading  module _ 

enum  mth_state_t  {READY,  DEAD}; 
typedef  struct  mth_st  *mth_t; 

struct  mth_st  {mth_t  next,  mth_state_t  state,  mctx_st  mctx}; 
mth_t  mth_current,  mth_rq; 
mctx_t  mctx_sched; 

void  mth_start  (int  stacksize,  void  *(*main)(void  *),  void  *arg); 
void  mth_spawn  (int  stacksize,  void  *(*func)(void  *),  void  *arg); 
void  mth_exit  (void  *value); 
void  mth_yield  (void); 
void  mth scheduler  (void); 


Figure  7.1:  Module  structure  and  pseudo-C  specification  of  MTH 
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Figure  7.2:  Threading  model  of  MTH 

make  cont  ext  ()  initializes  a  new  context  based  on  its  arguments  (location  of  new  context, 
stack  pointer,  return  link,  address  of  target  function,  and  argument  for  it);  the  stack  pointer 
of  the  new  context  points  to  a  stack  frame  prepared  for  the  target  function. 

Threading  model.  The  threading  module  provides  interfaces  for  all  the  "visible"  func¬ 
tionalities  of  MTH.  The  threading  model  is  illustrated  in  Figure  7.2  When  a  new  thread  is 
spawned,  it  is  put  into  a  ready  queue.  A  central  scheduler  removes  a  thread  from  the  ready 
queue  and  makes  it  the  current  thread  using  context  switching.  The  current  thread  may 
exit  execution  and  become  dead  or  yield  execution  and  be  put  back  into  the  ready  queue. 

A  user  program  starts  multi-threading  by  calling  mthjstartQ,  which  will  set  up  the 
threading  data  structures,  spawn  the  first  user  thread,  and  call  mth_scheduler()  to  initiate 
the  scheduling.  All  these  happen  on  the  statically  allocated  system  stack,  which  is  differ¬ 
ent  from  the  thread  stacks  to  be  allocated  on  the  heap.  The  scheduler  is  essentially  a  loop 
implementing  simple  FIFO  scheduling. 

The  thread  creation  function  mth_spaivn()  takes  three  arguments  describing  the  new 
thread:  the  stack  size,  the  location  of  the  thread  code,  and  the  thread  arguments.  It  al¬ 
locates  a  thread  stack  and  a  thread  control  block  (TCB),  creates  a  machine  context  for  the 
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thread,  and  puts  the  TCB  into  the  ready  queue.  Once  made  current  (or  running),  a  thread's 
execution  will  not  be  interrupted  unless  it  explicitly  yields  control  using  mth_yield(),  which 
transfers  the  control  to  the  scheduler  using  context  switching.  When  the  main  function  of 
a  thread  returns,  mth_exit  is  invoked  to  mark  the  thread  as  dead  and  yield  control  to  the 
scheduler.  Then,  the  scheduler  will  reclaim  the  resources  and  terminate  the  dead  thread. 

Machine-level  thread  implementations  like  MTH  pose  many  challenges  for  verifica¬ 
tion.  The  complex  and  subtle  behaviors  of  the  routines  are  difficult  to  model.  The  control 
flow  is  complex  with  the  extensive  use  of  embedded  code  pointers  stored  in  machine  con¬ 
texts  and  TCBs.  Furthermore,  the  invariants  maintained  by  the  threads  are  recursive  by 
nature,  because  the  threads  have  mutual  expectations  from  each  other. 

The  memory  module.  The  memory  module  is  self-contained,  as  described  by  the  spec¬ 
ification  below.  It  makes  use  of  a  free  list  ( flist )  of  memory  blocks  implemented  using 
the  queue  data  type.  Its  verification  is  adapted  from  that  of  a  malloc/ free  library  by  Yu  et 
al.  [63].  We  omit  the  details  and  instead  only  point  out  that  there  is  a  memory  invariant 
Imem  (essentially  stating  the  existence  of  the  free  list)  that  must  be  maintained  during  the 
execution  of  client  programs  of  this  module.  Its  use  will  be  illustrated  in  later  sections. 

mblk_t  t  =  Bsize.  t— Assize  *  t+A>— >  [size— 4]  A  size  >4 
lmem  —  3 tl.  node_t_ref(mblk_t,f/,//i,tf) 

malloc  :  Fn  size  {Aux  Local :  [28]; 

Pre  :  Imemi 

Post  :  Imem  *  retv— 4 1— >  size  *  retv ^  [size]} 

free  :  Fn  ptr  { Aux:;  Local:  [8]; 

Pre  :  lmem  *  ptr— Assize  *  ptn— >[size]'. 

Post  :  Imem} 
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Figure  7.3:  Machine  context 


7.2  Verification  of  the  Machine  Context  Module 

Machine  context  is  a  primitive  concept  for  low-level  programming.  It  offers  the  basis 
for  higher-order  control-flow  transfers,  such  as  call/ cc  and  threading.  As  is  the  case  of 
the  queue  and  memory  modules,  the  machine  context  module  is  specified  and  verified 
separately  without  any  knowledge  about  its  client — the  threading  module. 

What  is  a  machine  context?  Although  the  pseudo-C  specification  in  Figure  7.1  seems  to 
indicate  that  a  context  is  merely  eight  words,  the  actual  assumptions  behind  it  are  rather 
complex.  As  illustrated  in  Figure  7.3,  the  eight  words  represent  a  return  value  retv,  six 
registers  referred  to  collectively  as  cs,  (the  cs  convention  for  context  is  different  than  that 
of  ,  there  are  six  of  them,  instead  of  the  normal  four),  and  a  stack  pointer  sp.  sp  points  to 
a  return  address  ret  typically  found  on  top  of  a  stack  frame.  (A  machine  context  does  not 
really  care  about  other  part  of  the  stack,  or  if  there  is  a  stack  at  all).  The  six  saved  registers 
may  point  to  some  private  data,  (which  could  contains  the  other  part  of  the  stack).  There 
may  also  be  some  environment  data  shared  with  external  code.  Eventually,  a  context 
is  consumed  when  invoked.  A  proper  invocation  by  jumping  to  the  return  address  ret 
requires  (1)  the  saved  register  contents  be  restored  into  the  register  file,  (2)  the  stack  and 
private  data  be  preserved,  and  (3)  the  shared  environment  be  available.  In  other  words,  it 
is  only  safe  to  load  a  context  when  its  global  shared  data  is  available. 

All  these  requirements  make  it  difficult  to  specify  and  verify  the  seemingly  simple 
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manipulations  on  machine  contexts.  To  facilitate  the  reasoning,  we  define  a  macro  for  the 
context  data  structure  mctx_t(aem,,  mctx),  parametric  to  the  environment  described  as  a env. 

3retv, cs. sp.  ret .  apn, .  mctx^retv,cs,sp  *  spc^ret  *  a.pn, 

A  cptr(ref,  reg6(cs,sp+4)  A  ea x  =  retv  A  aenv  *  mctx^retv,cs,sp  *  sp*—>ret  *  a prv) 
where  apn,  describes  the  private  data,  and  reg6  describes  the  6  saved  registers  and  esp: 

reg  §(ebx,ecx,edx,esi,edi,ebp,esp)  =  ebx  =  ebx  A  ecx  =  ecx  A  edx  =  edx 

Aesi  =  esi  A  edi  =  edi  A  ebp  =  ebp  A  esp  =  esp 

Context  switching.  swapcontextQ  expects  two  pointers  (old  and  new  contexts)  as  argu¬ 
ments  and  performs  three  tasks:  to  save  registers  to  old  context,  to  load  registers  from  new 
context,  and  to  transfer  control  to  new  context.  Observations  from  inside  and  outside  of 
swapcontextQ  are  very  different.  From  the  code  of  swapcontextQ,  it  gets  called  by  one  client 
and  "returns"  to  another.  However,  this  is  transparent  to  the  clients — when  swapcontextQ 
returns  to  a  client,  the  stack  and  private  data  of  the  client  are  kept  intact. 

The  specification  and  proof  outline  of  swapcontextQ  is  given  in  Figure  7.4.  It  uses  a 
macro  Frig,  a  variant  of  Fn  obtained  by  replacing  reg  with  reg6  and  changing  cs  from  refer¬ 
ring  to  4  registers  to  6.  Similarly  to  Fn,  Fng  helps  to  manage  the  preservation  of  the  stack 
and  private  data.  In  addition,  the  pre-condition  of  the  specification  dictates  the  shape  of 
three  pieces  of  memory:  (1)  the  old  context  pointed  to  by  old — at  the  beginning  of  the  rou¬ 
tine  it  is  simply  32  bytes  of  memory  available  for  use,  (2)  the  shared  data  a env,  and  (3)  the 
new  context  pointed  to  by  new.  The  new  context  is  specified  with  help  of  the  macro  mctx_t. 
The  environment  parameter  of  this  macro  consists  of  two  parts:  the  shared  data  &env  and 
another  mctx_t  macro  describing  the  old  context.  This  is  because  the  old  context  will  be 
properly  set  up  by  the  routine  before  switching  to  the  new  one.  A  tricky  point  is  that  the 
old  context  will  be  expecting  a  new  (existentially  quantified)  shared  environment  &newenv. 
Although  some  may  expect  the  new  environment  to  be  simply  the  old  shared  aem,  together 
with  the  new  context  at  new,  this  may  not  necessarily  be  the  case.  For  instance,  the  new 
context  may  not  be  still  alive  when  the  old  context  regains  control.  The  post-condition  of 
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swapcontextQ  is  relatively  simple:  the  space  for  the  old  context  would  be  available  together 
with  the  new  shared  data  a newenv. 

An  interesting  proof  step  is  the  one  after  the  old  context  is  packed  but  before  the  new 
one  is  unpacked.  At  this  point,  there  is  no  direct  notion  of  stack  or  function.  The  relevant 
machine  state  essentially  comprises  of  two  contexts  and  one  environment: 

eax  =  new  A  mctx_t(a newenv,old)  *  aem, 

^  mCtX_t  (  mCtX_t(  ^newenv  old')  -fc  .  ne w  j 

It  is  therefore  safe  to  load  the  new  context  from  eax  and  switch  to  it.  More  proof  steps  are 
available  in  Figure  7.4. 

Context  loading.  loadcontextQ  essentially  performs  half  of  the  tasks  of  swapcontextQ, 
with  some  slight  difference  in  the  stack  layout.  Although  we  call  it  a  "function",  it  actu¬ 
ally  never  returns  and  does  not  require  the  stack  top  to  be  a  valid  return  address.  Instead 
of  using  Fn  macro,  we  only  write  the  following  as  its  complete  pre-condition.  We  present 
the  verification  of  loadcontextQ  in  Figure  7.5. 

Context  creation.  We  present  the  specification  and  proof  outline  of  makecontextQ  in  Fig¬ 
ure  7.6.  The  intermediate  assertions  are  organized  using  the  Fn  macro.  For  conciseness, 
we  omitted  common  parts  of  these  macros,  thus  emphasizing  only  the  changing  parts: 
the  stack  frame  Local  and  the  current  pre-condition  Pre. 

The  pre-condition  of  the  routine  specifies  (1)  an  empty  context  at  mctx,  (2)  a  stack  nsp 
with  available  space  of  size  nss,  (3)  some  private  data  of  the  target  context  (potentially 
accessible  from  the  argument  arg  of  the  function  funcQ  of  the  target  context,  (4)  a  link 
(return  address)  Ink  to  be  used  when  the  target  context  finishes  execution,  and  (5)  a  func¬ 
tion  pointer  funcQ  for  the  code  to  be  executed  in  the  target  context.  It  also  specifies  the 
exact  requirements  on  the  code  at  pointers  Ink  and  func:  (1)  am  occurs  both  in  the  post¬ 
condition  of  funcQ  and  in  the  pre-condition  of  Ink,  indicating  that  the  code  at  the  return 
address  Ink  may  expect  some  results  from  the  context  function  funcQ ;  (2)  the  stack  should 
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Fri6  old, new  {  Aux:  a newenv',  Local:  [0]; 

Pre:  old i— >  [32]  *  aenv  *  mctx_t(rnctx_t(a„evvem,,  old)  *  a env,new) ; 

Post:  old  !->•  [32]  *  a newenv  A  eax  =  0  } 

swapcontext:  // void  swapcontext  (mctxJ  old,  mctxJ  new); 

reg e(cs,sp)  Ass>0  A  stack (sp,ss,ret,old,new)  *  old i— >  [32]  *aprv*aem, 

*mctx4(mctx4(a„eM,(;„v,oM)  *  a env,new) 

Acptr (ret,  reg6(cs,sp+4)  Aeax  =  0  As\ack(sp+4,ss+4,old,new)  *  old *->•  [32]  *  apn,  *  anewenv) 

mov  eax ,  [esp+4]  //  load  address  of  the  context  data  structure  we  save  in 

mov  [eax+_eax]  ,  0  // all  registers  preserved  except  eax 

mov  [eax+_ebx]  ,  ebx 
mov  [eax+_ecx] ,  ecx 
mov  [eax+_edx] ,  edx 
mov  [eax+_esi] ,  esi 
mov  [eax+_edi]  ,  edi 
mov  [eax+_ebp] ,  ebp 
mov  [eax+_esp] ,  esp 

mov  eax ,  [esp+8]  //  load  address  of  the  context  data  structure  we  have  to  load 

eax  =  new  Ass>0  A  stack (sp,ss,ret,old,new)  *old^>0,cs,sp*a.prv*aLenv 
^ mctx_t ( mctx_t ( ^-newenv ,  old')  ^  a.gnv,riew) 

Acptrfret  ,req&{cs  ,sp+4)  Aeax  =  0  Astack(sp+4,ss+4,old,new)  *old i — >  [32]  *aprv*  a newenv) 

//shuffle  and  cast 

ea x=new  A  old^0,cs,sp  *  sp^ret  *s\&ck{sp,ss)  *  sp+4^old,new*  &prv 

Acptr  (ret,  reg6(cs,sp+4) 

Aeax  =  0  A  a newenv  *  °ld i  >  0,  cs,  sp*sp  i— >  ret  *  stack^p,  ss)  *  sp+4 i— »  old,  new  *  aprv) 

*3-env  *  rnctx_t(  rnctx_t  ( ^-newenv •  old )  ^  B.env,  new') 
//pack  old  context 

ea x=new  Amctx_t(a„ewrav,o/r/)  *  aenv  *  mctx_t(mctx_t(a„fVvenv,o/r/)  *a env,new) 
//  unpack  new  context 


ea x  =  new  A  mctxj(a„evm,v,  old)  *  a.env  *  new  i— >  retv' ,cs' ,sp'  *sp'  i— >  ret'  *  a newprv 
Acp\r(ret' ,  regies'  ,sp'  4-4) 

Aeax  =  retv1  A  mctx  J(a„ewem,,  oZd)  *  aenv  *  new  i— >•  retv1  ,cs' ,sp'  *  sp'  *— >  ret'  *  a newprv) 


mov  esp, 

[eax+_esp]  //  load  the  new  stack  pointer. 

mov  ebp, 

[eax+_ebp] 

mov  edi, 

[eax+_edi] 

mov  esi, 

[eax+_esi] 

mov  edx, 

[eax+_edx] 

mov  ecx, 

[eax+_ecx] 

mov  ebx, 

[eax+_ebx] 

mov  eax, 

[eax+_eax] 

reg6(cs',sp')  Aeax 

=  retv'  A  mctx_t(a„eH,e„V)  old)  *  aem,  *  new  i— » retv' ,cs' ,sp'  *  sp'  i— >  ret'  *  &newprv 

Acptr(r<?f'  ,reg6(cy'  ,sp' +4) 

Aeax  =  retv1  A  mctx  J{anewenv,  old)  *  aenv  *  new  i— ►  retv1  ,cs'  ,sp'  *  sp'  *— >  ret'  *  a  newprv) 

ret 


Figure  7.4:  Verification  of  machine  context  switching 
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loadcontext: 


//  void  loadcontext  (mctxJ  mctx); 


reg (cs,sp)  As\ack(sp  ,ss , ret , mctx)  *  aem,  *  mctx_t(stack (sp,ss,  ret, mctx)  *  a env,mctx) 


mov  eax,  [esp+4] 


eax = mctx  A  stack  (sp,ss,  ret, mctx)  *  aem>  *  mctxJ^stack^p,  ss,  ret, mctx)  *  a  env,mctx) 


I  I  unpack  context 


eax = mctx 


A  a„ 


n,  *  mctx_t(a„ 


,  mctx) 


I  I  unpack  context 


•  retv'  ,cs'  ,sp'  *  sp'  y 


•ret  *  a 


■prv 


eax  =  mctx  A  anewenv  *  mctx 

Acptr (ret' ,  regies'  ,sp' +4)  A  eax  =  retv1  A  anewenv  *  mctxv^y  retv'  ,cs' ,sp'  *  sp'  t—>ret'  *  aprv) 


mov  esp,  [eax+_esp]  //  load  the  new  stack  pointer. 

mov  ebp,  [eax+_ebp] 

mov  edi,  [eax+_edi] 

mov  esi,  [eax+_esi] 

mov  edx,  [eax+_edx] 

mov  ecx,  [eax+_ecx] 

mov  ebx,  [eax+_ebx] 

mov  eax,  [eax+_eax] 


rege(cs'  ,sp'+4)  A  ea x  =  retv'  A  a„ 
Acptr  (ret',  reg6(cs'  ,sp'+4)  Aeax=retv'  A  a„ 


,*  met  x^  retv' ,cs' ,sp'  *sp' y—>ret'  * ; 


,  *  mctx  r 


•  retv'  ,cs'  ,sp'  *  sp'  y 


'■prv 


•  ret'  *  aprv) 


ret 


Figure  7.5:  Verification  of  machine  context  loading 
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//  load  address  of  the  context  data  structure. 

//  load  new  stack  top 

//push  the  function's  argument  into  new  stack 

//  push  link  (return  address  for  the  function)  into  new  stack 

//push  the  function  as  return  IP  into  new  stack 


mov  eax,  [esp+4] 
mov  ecx,  [esp+8] 
mov  edx,  [esp+20] 
mov  [ecx-4] ,  edx 
mov  edx,  [esp+12] 
mov  [ecx-8] ,  edx 
mov  edx,  [esp+16] 
mov  [ecx-12] ,  edx 
sub  ecx,  12 

mov  [eax+_esp]  ,  ecx  //only  the  stack  pointer  matters  for  afresh  new  context 


Local:  [0];  Pre:  mctx*— *  [28], nsp—  I2*s\ack(nsp— 12, nss— 12,  func, Ink, arg)  *  &pn, 

Acp\r(lnk,  esp  =  nsp—4As\ack(nsp—4,nss—4,arg)  *aret) 

Acptr (func,  Fn  arg'  {  Local:  nss— 8; 

Pre:  sp'=nsp  —  8  A  arg'  =  arg  A  aenv  *  mctx>—>  [32]  *  aprv: 
Post:  aret }); 


//  unfold,  shuffle,  and  cast 


Local:  [0];  Pre:  mctx^retv1  ,cs' , nsp— \2*nsp—\2^  func 

*siack(nsp— 12, nss— 12)  *nsp—8^lnk,arg*aprv 
Acptr  (Ink,  esp  =  nsp—4As\ack(nsp—4,nss—4,arg)  *aret ) 

Acptr  (func,  reg6(cs'  ,nsp— 8)  Aea  x  =  retv'  A  aenv  *  mctx  ret  v' ,  cs' ,  nsp  —\2*nsp—\2^>  func 

*stack(nsp— 12,  nss— 12)  *  nsp— 8  >  Ink,  arg  *  &prv 
Acptr  (Ink,  esp  =  nsp—4As\ack(nsp—4,nss—4,arg)  *  aref)); 


//pack  the  fresh  context 


Local:  [0];  Pre:  mctx_t(a env,mctx)\ 


ret 


Figure  7.6:  Verification  of  machine  context  creation 
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Figure  7.7:  Thread  control  blocks  and  queues  of  MTH 


be  properly  maintained  upon  returning  to  Ink. 

The  post-condition  of  the  routine  simply  states  that,  when  make cont ext  ()  returns,  mctx 
will  point  to  a  proper  context  where  the  shared  environment  is  aem,. 

Our  interface  of  makecontextQ  is  faithful  to  the  Unix/Linux  implementations.  The 
heavy  usage  of  embedded  code  pointers  and  function  pointers  in  this  case  shows  how 
crucial  XCAP's  support  of  ECP  is.  As  the  proof  shows,  the  most  complex  step  is  again  on 
casting  code  pointers'  pre-conditions  and  pack  all  the  resource  into  a  complete  context. 


7.3  Verification  of  the  Threading  Module 

With  all  the  other  modules  verified,  we  are  now  ready  to  tackle  the  threading  module. 

Thread  control  blocks  and  thread  queues.  The  main  data  structure  for  MTH  threading 
is  the  thread  control  block  (TCB).  Figure  7.7  presents  a  queue  of  TCB's.  Every  TCB  com¬ 
prises  of  three  parts:  (1)  the  first  word  is  a  link  field  for  the  queue,  (2)  the  second  word 
stores  the  status  of  the  thread  (READY  or  DEAD),  and  (3)  a  machine  context  is  embedded  in 
the  next  eight  words.  The  TCB's  of  all  ready  but  non-running  threads  are  put  into  a  ready 
queue,  implemented  as  an  instance  of  the  polymorphic  queue  introduced  in  Section  6.3. 

mth  _t_ref(rf,  a  im,,tl,q)  =  node  _t_ref(mth  Jt(st ,  a  inv)  ,tl,q). 

As  a  reminder,  node  t  ref  requires  three  parameters:  a  predicate  describing  the  queue 
nodes,  a  list  of  node  locations,  and  a  queue  pointer,  mth  t  ref  requires  4  parameters:  (1) 
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Figure  7.8:  Threading  invariant  of  MTH 


every  thread  in  the  queue  has  the  same  thread  state  st,  (2)  a  certain  threading  invariant 
a i„v  that  must  be  established  before  any  thread  in  the  queue  takes  control,  (3)  a  list  tl  of 
TCB  handles  in  the  queue,  and  (4)  the  queue  pointer.  Note  that  there  should  be  a  threading 
invariant  expected  by  each  thread's  context  when  being  switched  to.  Since  this  invariant 
is  not  yet  known,  we  name  it  as  a These  arguments  are  organized  properly  to  feed  the 
node_t_ref  macro.  In  particular,  the  content  of  a  TCB  (excluding  the  link  field)  must  satisfy 
mth_t(sf,  a inv),  which  is  defined  as: 

Xmth.  mth+4\-^ st  *  mctx_t(lmem  *  a„n, (m? /i) , mr/7 + 8 ) 

In  short,  a  TCB  at  mth  satisfies  the  mth  t  macro  if  the  state  st  is  located  at  offset  4  and  a 
valid  context  is  located  at  offset  8.  Besides  the  threading  invariant  a ,„v  (to  be  provided  by 
the  current  thread),  the  context  also  expects  the  invariant  lmem  of  the  memory  module. 

Threading  invariant.  Figure  7.8  illustrates  the  run-time  threading  data  structures  and 
invariants.  There  are  three  entities  involved:  a  scheduler  context,  a  TCB  of  the  running 
thread,  and  a  ready  queue,  each  pointed  to  by  a  global  memory  address.  When  a  thread 
yields  or  exits,  the  scheduler  context  is  invoked  to  do  the  scheduling. 

A  thread  expects  such  an  environment  to  be  properly  maintained  before  taking  con¬ 
trol.  Meanwhile,  itself  is  also  part  of  such  kind  of  environment  for  other  threads.  There¬ 
fore,  the  threading  invariant  is  inherently  recursive,  as  modelled  in  the  following: 
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Icore  —  /Lta.Xst,cur.  3sched,tl. 

mctx_schedi -^sched  *  mctxJ(sched_env(a),sc/?cd) 

*  mth_cun— >cur  *  cur\-^_,st 

*  mth_t_ref (READY,  a( READY) , tl,  mth_rq) 

The  last  three  lines  correspond  to  the  three  items  in  Figure  7.8,  respectively.  The  recursive 
variable  a  essentially  represents  lcore  itself,  which  is  exactly  the  threading  invariant  that 
every  TCB  expects.  Note  that  this  invariant  only  describes  the  parts  inside  the  dashed 
lines  in  Figure  7.8 — the  context  of  the  current  thread  is  not  part  of  its  own  shared  environ¬ 
ment  (nevertheless,  each  thread's  context  considers  all  other  threads'  contexts  as  part  of 
its  shared  environment). 

The  environment  of  the  scheduler's  context,  described  above  using  schecLenv,  de¬ 
serves  further  explanation.  We  use  the  macro  sched  env(a/m,)  to  represent: 

3st,cur.  Imem  *  mctx.sched^sc/jed 

*  mth_cun— >cwr  *  cur^>_,st 

*  rnth_t_ref(READY,aim, (READY),?/, mth_rq) 

*((s?  =  READY  A  mctx_t(lmem  *  aim,(READY, cur), cur+8))  V 
(rf  =  DEAD  A  3size.  cur— Assize  *  cur+8>— ►  [size— 8])). 

The  first  three  lines  describe  the  existence  of  the  scheduler  pointer  (not  the  scheduler 
context),  the  running  thread,  and  the  ready  queue.  When  the  scheduler  takes  control, 
there  must  have  been  a  user  thread  that  yielded.  The  last  two  lines  describe  the  context  of 
that  yielding  thread — based  on  whether  the  thread  is  still  alive  as  indicated  by  the  state 
field  st,  there  would  be  either  a  proper  context  or  the  corresponding  space  available. 

The  lcore  macro  is  instantiated  with  the  READY  state  and  a  running  thread  before  used 
as  the  invariant  of  the  threading  module: 

lfUn (cur)  =  lcore (READY, cur)  *  cwr+8t— ►  [32] 

The  cur  pointer  of  the  running  thread  is  irrelevant  to  the  clients  of  the  threading  module. 
The  external  invariant  used  when  importing  the  threading  module  is  simply 
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I  mth  —  Ifull(-) 

where  _  is  a  wildcard.  We  also  define  a  syntactic  sugar  to  describe  the  ready  queue: 
ready  _queue(d,mth_rq)  =  mth_t_ref(  READY,  lcore(READY),t/,mth_rq). 

Thread  yielding.  The  most  frequently  used  threading  routine  should  be  mth_yield (),  im¬ 
plemented  as  a  context  switch  from  the  current  (running)  thread  to  the  scheduler.  Fig¬ 
ure  7.9  gives  its  specification  and  proof  outline.  Similar  to  swcipcontext(),  Frig  is  used  here. 
After  unpacking  the  threading  invariant,  pointers  to  the  contexts  of  the  current  thread 
and  the  scheduler  are  pushed  onto  the  stack.  A  call  to  swapcontext( )  completes  the  yield¬ 
ing.  As  indicated  in  the  assertions,  the  thread's  context  expects  both  the  memory  and 
the  threading  invariants  to  be  maintained  before  it  takes  control  again.  Interested  readers 
could  refer  to  Figure  7.4  to  better  understand  the  verification. 

Thread  creation.  Dynamic  thread  creation  is  also  a  basic  requirement  for  thread  imple¬ 
mentations.  Just  as  mth  yieldQ  relies  on  swapcontextQ  to  perform  switching,  mth  spawnQ 
creates  a  new  thread  with  the  help  of  make cont ext  ().  When  creating  a  new  thread,  one 
should  specify  the  size  ( stacksize )  of  the  thread  stack,  a  pointer  ( func )  to  the  thread  code, 
and  an  argument  pointer  ( arg )  for  the  thread  code.  The  data  at  arg  is  described  by  an 
existentially  quantified  predicate  apre  that  describes  the  private  data  prepared  for  funcQ. 
mth  spawnQ  will  call  mallocQ  to  allocate  a  big  chunk  of  memory,  divide  it  into  the  TCB 
and  the  stack  of  the  new  thread,  initialize  TCB,  call  makecontext  ()  to  build  the  new  thread 
context,  and  call  queue  JnsertQ  to  append  the  new  thread  onto  the  ready  queue.  The  veri¬ 
fication  of  mth  spawnQ  is  presented  in  Figure  7.10  and  Figure  7.11. 

The  pre-  and  post-conditions  of  mthspawnQ  require  that  the  memory  and  threading 
invariants  be  maintained,  which  is  necessary  for  verifying  the  memory  allocation  and 
threading  operations  in  the  code.  The  pre-  and  post-conditions  of  funcQ,  as  asserted  with 
cptr,  also  maintain  the  same  invariants.  In  addition,  funcQ  is  to  be  invoked  with  the  given 
argument  arg.  The  post-condition  of  funcQ  involves  the  invariants  only.  This  indicates 
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mov  eax,  [mctx_sched]  // eax  not  preserved 
push  eax 

mov  eax,  [mth_cur] 
add  eax,  8 
push  eax 


ret 


Figure  7.9:  Verification  of  thread  yielding 
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mov  ecx,  [esp+8] 

add  ecx,  size_of _mth_st 

push  ecx  //allocate  a  new  thread  control  block 


Local:  [52], 40+5? acksize',  Pre:  Imem  *  ready  _queue(f/,  mth  _rq)  *  &pre  Astacksize>  12 

A  cptr (func,  Fn  arg'  {  Local  :  [st acksize— 8]; 

Pre.  arg  =cirg  A  Imem  *  Imth  *  apre> 
Post .  I  mem  *  I  mth  }  )  > 

call  malloc  // mth  J  t  -  (mth_t)malloc(sizeof(mthst)+stacksize); 

Local:  [52], 40 -\-st acksize',  Pre:  lmem  *  ready _queue(f/,mth_rq)  *  ccpre  *t—4^40+stacksize 

*  1 1— » [40 +st  acksize]  A  eax  =  t  A  st  acksize  >12 
A  cptr  (func,  Fn  arg'  {  Local  :  [st  acksize— 8]; 

Pre:  arg  =arg/\  Imem*  Imth*  &-pre\ 
Post .  I  mem  *  I  mth  }  )  > 

pop  ecx 

mov  [eax+_state]  ,  READY  // t->state  —  READY; 
mov  edx,  [esp+16] 
push  edx 

mov  edx,  [esp+12] 
push  edx 
push  mth.exit 
add  ecx,  eax 
push  ecx 
add  eax,  _mctx 
push  eax 


Figure  7.10:  Verification  of  thread  creation 
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Local:  [36},t+8,t+40+stacksize,  mth.exit ,func,arg\ 

Pre:  lmem  *  ready_queue(f/,rnth_rq)  *  apre  *t—4>-^ 40+stacksize  *t>—>  ,  READY*f+8(— >  [32] 
*  stack(t +40 +stacksize.stacksize)  A stacksiz.e  >  12 
A  cptr(mth_exit,  esp  =  sp  Astack^p,^)  *  lmem  *  If U\\(cur)  *cur—4^size 

*  sp  i— ►  [size  —  40  —  .s\y]  Ass=sp— cur— 40) 

A  cptr (func,  Fn  arg'  {  Local :  [stacksize— 8]; 

Pre.  arg  =arg  A  lmem  *  lmth  * 

Post :  I  mem  *  I  mth  }  )  \ 

call  makecontext  // makecontext(&t->mctx,  t+sizeof(mth.st)+stacksize, 

//  mth  .exit, func, arg); 

Local:  [36], t +8+ +40+ stacksize,  mth.exit ,func,arg\ 

Pre:  lmem  *  ready_queue(f/,mth_rq)  *t  i->_,  READY  *  mctx_t(lmem  *  lcore(READY,f),f+8) 
pop  eax 
add  esp,  16 
sub  eax,  _mctx 
push  eax 
push  mth_rq 


add  esp,  4 
pop  eax 


Local:  [56];  Pre:  lmem*ready_queue(r/@[f],mth_rq) 
ret 


Figure  7.11:  Verification  of  thread  creation  (continued) 

that  the  data  of  apre  must  be  properly  deallocated  before  fund)  finishes,  leaving  no  possi¬ 
bility  of  space  leaks.  Finally,  the  post-condition  of  mthjspawn)  does  not  explicitly  refer  to 
the  newly  spawned  thread,  which  would  be  in  the  ready  queue  as  part  of  lmth- 


Thread  termination.  mth.exit  is  a  routine  that  mthspawnQ  supplies  as  the  return  link 
for  newly  created  contexts.  It  is  invoked  when  a  thread  finishes  execution  and  returns 
from  its  main  function.  The  verification  of  mth.exit  is  presented  in  Figure  7.12.  The  code 
simply  sets  the  state  of  the  current  thread  to  be  DEAD  and  transfers  the  control  to  the 
scheduler  with  loadcontext().  Since  it  is  not  a  function,  we  can  not  use  Fn  syntax  to  present 
its  pre-condition.  The  proof  involves  the  common  packing  and  unpacking  of  the  thread- 
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mth.exit: 


esp  =  5p  Astack(5/?,55)  *  lmem  *  lfUn(cwr)  *cur— Assize  *sp^  [size  —  40  —  55] 

A55 = sp — cur — 40  A  55  >  8 

//  unfold,  shuffle 

esp  =  sp  A  stack(5/j,  55) 

*cur— Assize  *cur+S^  [32]  *  sp<— >  [size  —  40  —  55]  Ass=sp— cur— 40  A  55  >8 
*lmem  *  mctx.schedi— >5c/i<?fi?  *  mth.curi cur*  cur  READY  *  ready_queue(/Z,  mth_rq) 

*mctx_t(sched_env(lC0re),  sched) 
mov  eax,  [mth.cur] 

mov  [eax+_state]  ,  DEAD  //  mthxur->state  =  DEAD; 
mov  eax,  [mctx.sched] 
push  eax 

esp  =  5/7— 4  A  stack(5p— 4, 55— 4,  sched) 

*cur—4*—>  size  *  cur-Eft*-^  [32]  *  sp<— >  [size  —  40  —  55]  Ass  =  sp— cur— 40  A 55 >8 

*lmem  *  mctx_sched  ^ sched  *  mth.cur  ^cur*cur^  DEAD  *  ready _queue(fZ,  mth_rq) 
*mctx_t(sched_env(lC0re),  sched) 

I  I  unfold,  shuffle,  cast 

esp  =  sp— 4  Astack(5p— 4,55— 4,  sched) 

*cur—4^  size  *  cur+Sf-^  [32]  *sp  1— >  [size  —  40  —  55]  Ass  =  sp— cur— 40  A55>  8 
*lmem  *  mctx_sched  ^ sched  *  mth_cur  ^-cur*cun-^  ,  DEAD  *  ready _queue(fZ,  mth_rq) 
*rnctx_t(lmem  *  mctx_schedi-^5cZ7erZ  *  mth_curi ~^cur*cur^>_,  DEAD  *  ready_queue(fZ,mth_rq) 
*cur — 4 1 — >  size  *  cur +8 1— >  [5/ze — 8] ,  sched ) 
call  loadcontext  // loadcontext(mctxxched); 


Figure  7.12:  Verification  of  thread  termination 

ing  invariant.  In  addition,  it  combines  the  TCB  and  stack  of  the  dead  thread  into  one 
continuous  memory  block,  which  is  to  be  freed  by  the  scheduler. 


Threading  initialization.  Multi-threading  is  started  by  calling  mthxtartQ.  This  function 
spawns  the  main  thread,  allocates  the  scheduler  context,  and  establishes  the  global  data 
structures  used  in  the  threading  invariant  of  Figure  7.8.  It  starts  thread  scheduling  by 
invoking  mthjschedulerQ,  which  will  return  only  after  all  threads  are  dead  and  deallocated. 
mthxtart ()  then  deallocates  the  scheduler  context  and  returns  to  the  user  program.  We 
present  the  verification  of  mthxtartQ  in  Figure  7.13. 
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Fn  stacksize, main, arg  {  Aux:  ;  Local:  [72]; 

Pre:  lmem  *  mctx_sched  !->■_*  mth_cur  i— >  _  *  mth  _rq  i— >  *  apre  A  stacksize  >12 

Acptr(mazn,  Fn  arg'  {  Local  :  [stacksize  —  8] ; 

Pre.  arg  =arg  A  lmem  *  Imth  *  apre> 
Post,  lmem  *  Imth  } )i 

Post:  lmem  *  mctx_sched  t— >  _  *  mth_cun— ►  _ *  mth  _rq  i— >  _  } 

mth.start:  // void  mthstart  (int  stacksize,  void  *(*main)(void  *),  void  *arg); 

Local:  [72];  Pre:  lmem*mctx_schedi-^_*mth_curH-s-_*mth_rqi— t_*apre  Astacksize>  12 

Acptr(maz'«,  Fn  arg'  {  Local  :  [stacksize  —  8]; 

Pre.  arg  =  arg  A  lmem  *  Imth  * 

Post,  lmem  *  Imth  } )i 

mov  [mth_rq]  ,  NULL  //  mth  rq  =  NULL; 

Local:  [72];  Pre:  lmem  *  mctx_schedi— >_*  mth_curH-s-_*  ready_queue([],mth_rq)  *  apre 

A  stacksize  >  12  Acptr  {main,  Fn  arg'  {  Local  :  [stacksize  —  8]; 

Pre:  arg  =arg  A  lmem  *  Imth  * 

Post,  lmem  *  Imth  } )> 

mov  eax,  [esp+12]  // initialize  the  ready  thread  queues 

push  eax 

mov  eax,  [esp+8] 

push  eax 

mov  eax,  [esp+4] 

push  eax 

call  mth_spawn  //  mth  spaivn( stacksize,  main,  arg); 

add  esp ,  12  //  spawn  a  thread  for  the  main  program 

Local:  [72];  Pre:  lmem*iTictx_schedi->-_*mth_curi->_*ready_queue([mam],mth_rq) 

push  size_of _mctx_st 

call  malloc  // mctx_sched  -  (mctx_t)malloc(sizeof(mctx_st)); 
add  esp,  4 

mov  [mctx_sched]  ,  eax 

Local:  [72]; 

Pre:  lmem  *  mctx_sched  sched  *  sched  i->  [32]  *  mth  cun—  *  ready  queue  ([mam],  mth  rq) 

call  mth.scheduler  //  mth  scheduler  ();  H  do  the  threading 

Local:  [72]; 

Pre:  lmem  *  mctx_sched^  sched  *  sched  i->  [32]  *  mth_curi->_*  ready_queue([],mth_rq) 

mov  eax,  [mctx_sched] 
push  eax 

call  free  H freeimctx  sched); 

add  esp,  4 

Local:  [72];  Pre:  lmem*nictx_schedH^sc/zed*mth_curi— >_*ready_queue([],mth_rq) 

//  cast 

Local:  [72];  Pre:  lmem*rnctx_schedi-^_*mth_curH-s-_*mth_rqi— *•_ 

ret 


Figure  7.13:  Verification  of  thread  initialization 
104 


Fn  {  Aux:  ;  Local:  [16]; 

Pre:  lmem  *  mctx_sched  *->•  sched  *  sched  i— >  [32]  *  mth.cur i— *•  _  *  ready_queue(fi,  mth_rq) ; 

Post:  lmem  *  mctx_sched  i->  sched  *  sched  ^  [32]  *  mth.cun— >  _*  ready_queue([],  mth_rq) } 

mth_scheduler:  // void  mth_scheduler  (void); 

Local:  [16]; 

Pre:  lmem  *  mctx_sched^  sched  *  sched  i->  [32]  *  mth_cun— >_*  ready_queue(/7,mth_rq) 

push  mth_rq  //while  (mthxur  =  queue  jdelete(&mthxq))  !=  NULL) 

call  queue_delete 
add  esp,  4 

Local:  [16]; 

Pre:  lmem  *  mctx_sched  sched  *  sched i->  [32]  *  mth_cun-^_*  ready_queue(f/',mth_rq) 

Aeax  =  retv  A  ((retv  =  NULL  A  tl  =  tl'  =  [])V 

(refv^NULL  Atl  =  retv  ~tl'  Aretvi— >_*  mth_t( READY,  lcore ( READY),  retv))) 

cmp  eax,  NULL 
je  sc_ret 

Local:  [16]; 

Pre:  lmem  *  mctx_sched  sched  *  sched i->  [32]  *  mth_cun-^_*  ready_queue(f/',mth_rq) 

Aeax  =  retv  A  retv NULL  A  tl  =  retv ::  tl'  A  retv  !—>■_*  mth_t(READY,  lcore(READY) ,  retv) 

mov  [mth_cur]  ,  eax  // Found  next  ready  thread 
add  eax,  _mctx 
push  eax 

mov  eax,  [mctx.sched] 

push  eax  //  ENTERING  THREAD  -  by  switching  the  machine  context 

Local:  [S\, sched,  retv+8; 

Pre:  lmem  *  mctx_sched  sched  *  sched i->  [32]  *  mth_curi->reiv*  ready  _queue(t/',mth_rq) 

Aeax  =  retv  A  retv  f  NULL  Atl  =  retv :tl'  A  retv<-^  _*  mth_t( READY,  lcore(READY),retv) 

//  unfold,  shuffle,  cast,  rename 

Local:  [S\, sched,  retv+8; 

Pre:  sched i— » [32] 

*lmem  *  mctx_sched  i— >•  sched  *  mth.cur  i— >•  cur  *  cur  i->  READY  *  ready _queue(f/',  mth_rq) 
*mctx  t(lmem  *  mctx_schedi— s-sc/red  *  mth_cun— >cur  *cur>-^  ,  READY  *  ready _queue(d',  mth_rq) 
*mctx_t(sched_env(lC0re) ,  sched) ,  cur+ 8) 

call  swapcontext  // swapcontext(mctx_sched,  &mthxur->mctx); 

Local:  [S\, sched,  retv+8; 

Pre:  sched i— »  [32] 

*lmem  *  rnctx_sched  i  ^  sched  *  mth_cur  cur  *  cun-^-  _,st  *  ready _queue(fi,  mth_rq) 

*((st  =  READY  A  mctx_t(lmem  *  lC0re(READY,cwr),cMr+8))  V 
(st  =  DEAD  A  ~lsize. cur— A *—> size  *  cur+8\—>  [size— 8])) 

add  esp,  8 

mov  eax ,  [mth_cur]  //  If  previous  thread  is  now  marked  as  dead,  kick  it  out 
mov  ecx,  [eax+_state] 

cmp  ecx,  DEAD  // if (mth_cur-> state  ==  DEAD) 

jne  sc_els 


Figure  7.14:  Verification  of  thread  scheduler 
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Local:  [16]; 

Pre:  sched  ^  [32]  *  lmem  *  mctx.schedi-^i'c/ird  *  mth.cur  i— >  cur  *  ready_queue(f/.  mth_rq) 

Ast  =  DEAD  A  cur^  _,st  *cur— 4  i—>size  *cur+8t-^>  [size— 8]  A  ea x=cur 

//  cast 

Local:  [16]; 

Pre:  lmem  *  mcXx.sched*-^ sched  *  sched [32]  *  mth.cur  i-»  cur  *  ready_queue(f/,  mth_rq) 

Acur— 4 1— >  size  *  cur  i— >  [size]  A  eax  =  cur 

push  eax 

call  free  // free(mth_cur); //No  stack from  now  on 

add  esp,  4 

Local:  [16]; 

Pre:  lmem  *  mc\x_sched*-^ sched  *  sched [32]  *  mth.cur  i— >  cur  *  ready_queue(f/,  mth_rq) 

jmp  mth_scheduler 

Local:  [16]; 

Pre:  sched  i->  [32]  *  lmem  *  mctx_sched  sched  *  mth.cur  i->  cur  *  ready_queue(f/,  mth_rq) 

A st  =  READY  Acur\-^f  _,st  *  mctx_t(lmem  *  lcore(READY,a/r),a/r+8)  Aea x  =  cur 

sc_els:  H  cast 

Local:  [16]; 

Pre:  lmem  *  mctx_sched  i— >  sched  *  sched  h->  [32]  *  mth.cur  i->  cur  *  ready_queue(/7,  mth_rq) 

Acur*-^  _*  mthJ (READY,  lC0re(READY),cr<r)  A  eax  =  cur 

push  eax  //  else 

push  mth_rq  //  insert  last  running  thread  back  into  this  queue 

call  queue.insert  // queue  Jnsert(&‘mth_rq,  mthxur); 
add  esp,  8 

Local:  [16]; 

Pre:  lmem  *  mctx_sched h- > sched  *  sched *—>  [32]  *  mth.cun— >cur*  ready_queue(f/@  [car],  mth_rq) 

jmp  mth_scheduler 

Local:  [16]; 

Pre:  lmem  *  mc\x_schedt-> sched  *  sched [32]  *  mth_cun— >_*  ready_queue(i/',mth_rq) 

A  eax  =  retv  A  retv  =  NULL  A  tl  =  tl'  =  [] 

sc_ret:  //  cast 

Local:  [16]; 

Pre:  lmem  *  mctx_sched  i->  sched  *  sched  [32]  *  mth_curi->_*  ready_queue([],mth_rq) 

ret 


Figure  7.15:  Verification  of  thread  scheduler  (continued) 
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Thread  scheduler,  mth .scheduler 0  is  essentially  a  loop  implementing  FIFO  scheduling. 
It  is  directly  invoked  only  by  mth_start().  Upon  entering  mthschedulerQ,  the  scheduler 
context  and  some  other  threading  data  structures  are  already  in  place.  If  the  ready  queue 
is  not  empty,  mthschedulerQ  removes  the  first  thread,  sets  it  as  the  current  thread,  and 
switches  to  it  using  swapcontextQ.  The  scheduler  resumes  execution  when  the  current 
thread  yields  or  exits,  at  which  point  the  scheduler  either  puts  the  yielding  thread  into 
the  ready  queue  or  deallocates  it  based  on  the  thread  state.  The  scheduler  finally  returns 
when  the  ready  queue  becomes  empty.  We  give  the  specification  of  mthschedulerQ  as  fol¬ 
lows,  again  omitting  the  details  for  space.  The  post-condition  of  mth  scheduler  preserves 
everything,  except  that  there  no  thread  in  the  ready  queue. 

We  present  the  verification  of  mthschedulerQ  in  Figure  7.14  and  Figure  7.15.  The  sched¬ 
uler  context  to  be  stored  in  the  threading  invariant  is  captured  by  swapcontextQ  when  the 
scheduler  calls  it  to  switch  to  the  new  current  thread. 

7.4  Discussion 

First,  we  want  to  emphasize  that  the  threading  module  refers  to  other  utility  modules  only 
through  the  interfaces.  For  example,  the  memory  invariant  lmem  is  used  in  the  thread¬ 
ing  specifications,  but  only  propagated  abstractly  during  the  verification  in  the  local¬ 
reasoning  style  of  separation  logic.  It  is  therefore  safe  to  upgrade  the  implementations 
of  the  utility  modules  without  affecting  the  threading  verification.  Within  the  threading 
module,  one  may  upgrade  the  FIFO  scheduler  without  affecting  other  threading  routines. 
In  fact,  one  may  even  have  mthstartQ  be  parameterized  by  a  scheduler  function  with  only 
minor  changes  in  the  proof  structure. 

The  large  and  complex  proof  naturally  raises  practicality  concerns.  However,  when 
being  compared  with  other  verification  methods  and  judging  practicalities,  there  are  two 
aspects  of  our  method  that  need  to  be  taken  into  consideration. 

For  comparison  with  analysis-  and  test-based  software  verification  methods  in  gen- 
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eral,  the  important  question  to  ask  is  what  kind  of  guarantee  it  can  deliver.  Many  of 
these  tools  can  automatically  find  bugs  in  millions  of  line  of  system  code,  but  only  in  a 
"best-effort"  fashion — both  the  programmer  and  the  end  user  expect  bugs  to  appear  and 
patches  to  be  released.  In  our  case,  we  want  to  completely  exclude  certain  categories  of 
bugs,  as  guaranteed  by  the  language-based  approach  used  in  this  dissertation.  So  the  first 
choice  programmers  should  make  is  whether  they  just  want  to  find  bugs  in  applications 
or  make  rigorous  claims  and  provide  warranty  about  kernels. 

For  comparison  with  other  language-based  methods,  such  as  traditional  type  systems, 
the  important  question  to  ask  is  what  kind  of  target  code  is  actually  supported.  Since  there 
is  no  sound  type  systems  for  C  and  assembly,  there  have  been  many  efforts  on  building 
the  complete  system  kernels  in  higher-level  type  safe  languages,  all  with  trade-offs  in  effi¬ 
ciency  and/ or  compatibility,  some  even  with  significant  changes  in  programming  style.  In 
our  case,  we  require  no  change  to  the  existing  system  programming  style  and  code  base, 
thus  expect  no  performance  or  compatibility  issue  when  putting  into  real  use.  In  general, 
we  believe  that  low-level  system  code,  mid-level  infrastructure  code,  and  high-level  ap¬ 
plication  code  require  different  levels  of  safety  guarantees.  Thus  their  verifications  will 
naturally  result  in  different  levels  of  productivity.  In  fact,  the  6  person-month  spent  may 
be  a  fair  price  to  pay,  considering  that  the  code  is  critical  and  heavily  relied  upon. 

By  targeting  at  a  thread  library,  a  piece  of  system  code  that  is  commonly  recognized  as 
complex  and  never  fully  verified  with  traditional  approaches,  we  demonstrate  the  feasi¬ 
bility  of  using  XCAP  frameworks  for  the  mechanical  verification  of  realistic  machine-level 
code.  That  being  said,  at  the  current  stage,  the  abstraction  level  used  in  this  dissertation  is 
best  suited  for  verifying  critical  small-scale  software  such  as  core  system  libraries.  Much 
further  study  is  needed  to  scale  the  basic  framework  for  better  productivity.  One  direc¬ 
tion  is  to  scale  the  verification  from  assembly  level  to  C  level,  which  should  dramatically 
increase  the  productivity  of  verifications. 
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Chapter  8 


The  Coq  Implementations 


One  key  feature  of  the  XCAP  framework  is  mechanization.  We  mechanize  not  only  our 
machine  syntax,  machine  semantics,  assertion  languages,  interpretations,  inference  rules, 
and  program  specifications  and  proofs,  but  also  the  complete  meta  theory  of  XCAP,  in  a 
general  mathematic  logic.  Furthermore,  we  want  to  direct  have  the  power  of  higher-order 
predicate  logic,  through  a  shallow  embedding.  For  these  reasons,  our  usage  of  the  Coq 
proof  assistant  [58]  is  to  treat  it  as  both  a  mechanized  logic  framework  and  a  mechanized 
meta  logic  framework,  as  explained  in  Section  2.2. 

In  this  chapter,  we  first  discuss  our  Coq  implementations  for  the  meta  theory  of  PropX 
interpretation,  for  both  predicative  and  impredicative  versions.  Then  we  discuss  the  im¬ 
plementation  of  XCAP  inference  rules  and  meta  theory.  Based  on  that,  we  present  the 
difference  with  the  implementation  of  XCAP86.  Finally,  we  discuss  our  implementation 
for  the  certified  mini  thread  library  in  the  previous  chapter. 

We  point  out  that  although  our  implementation  and  presentation  in  this  dissertation 
use  CiC/Coq  as  the  mechanized  meta  logic,  in  theory  it  is  possible  to  implement  XCAP 
upon  other  mechanized  meta  logics. 
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8.1  Implementation  of  PropX 


For  the  extended  propositions  in  Section  3.2,  we  define  it  as  the  following. 

Inductive  PropX  :  Type 


=  cptr:  Word  ->  (State  ->  PropX) 

->  PropX 

1  prop :  Prop 

->  PropX 

1  andx:  PropX  ->  PropX 

->  PropX 

1  orx  :  PropX  ->  PropX 

->  PropX 

1  impx:  PropX  ->  PropX 

->  PropX 

1  allx:  forall  A,  (A  ->  PropX) 

->  PropX 

1  extx:  forall  A,  (A  ->  PropX) 

->  PropX 

The  encoding  uses  higher-order  abstract  syntax  (HOAS)  [52]  to  represent  extended 

predicates.  Interpretation  of  extended  propositions  is  defined  as  a  recursive  function. 

Definition  Assertion  :=  State  ->  PropX. 

Definition  CdHpSpec  :=  Map  Label  Assertion. 

Fixpoint  Itp  (P  :  PropX)  (Si  :  CdHpSpec)  {struct  P}  :  Prop 
:=  match.  P  with 

I  cptr  1  a  =>  lookup  Si  1  a 
I  prop  p  =>  p 

I  andx  P  Q  =>  Itp  P  Si  /\  Itp  Q  Si 

I  orx  P  Q  =>  Itp  P  Si  \/  Itp  Q  Si 

I  impx  P  Q  =>  Itp  P  Si  ->  Itp  Q  Si 

I  allx  A  P  =>  forall  x,  Itp  (P  x)  Si 

I  extx  A  P  =>  exists  x,  Itp  (P  x)  Si 

end. 

And  the  interpretation  of  assertions  is  a  simple  lift. 


Definition  ItP  a  Si  S  :=  Itp  (a  S)  Si. 


For  the  XCAP  with  impredicative  polymorphism  defined  in  Section  4.1  and  Section  4.3 
the  HOAS  encoding  of  extended  propositions  no  longer  works.  The  positivity  require¬ 
ment  in  Coq  inductive  definition  limits  the  type  A  of  the  quantified  terms  to  be  of  lower 
level  than  PropX,  which  can  not  be  used  for  impredicative  quantifications.  We  use  de 
Bruijn  notations  [15]  to  encode  them,  but  keep  using  HOAS  for  all  other  constructors. 
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Inductive  PropX 

list  Type 

->  Type  : 

= 

1 

var 

forall 

L  A,  A 

-> 

PropX 

(A 

1 

lift 

forall 

L  A,  PropX 

L 

-> 

PropX 

(A 

1 

cptr 

forall 

L,  Word  -> 

(State  -> 

PropX 

L) 

-> 

PropX 

L 

1 

ref 

forall 

L,  Word  -> 

(Word  -> 

PropX 

L) 

-> 

PropX 

L 

1 

prop 

forall 

L,  Prop 

-> 

PropX 

L 

1 

andx 

forall 

L,  PropX  L 

->  PropX 

L 

-> 

PropX 

L 

1 

orx 

forall 

L,  PropX  L 

->  PropX 

L 

-> 

PropX 

L 

1 

impx 

forall 

L,  PropX  L 

->  PropX 

L 

-> 

PropX 

L 

1 

allx 

forall 

L  A,  (A  -> 

PropX  L) 

-> 

PropX 

L 

1 

extx 

forall 

L  A,  (A  -> 

PropX  L) 

-> 

PropX 

L 

1 

allv 

forall 

L  A,  PropX 

(L  ++  A  : 

:  nil) 

-> 

PropX 

L 

1 

extv 

forall 

L  A,  PropX 

(L  ++  A  : 

:  nil) 

-> 

PropX 

L 

1 

mu 

forall 

L  A,  (A  -> 

PropX  (L 

++  A  : 

nil) ) 

->  A  -> 

PropX 

L. 

L) 

L) 


We  can  also  define  some  syntactic  sugars  for  PropX. 

Notation  "<<  p  >>"  :=  (prop  p  )  (at  level  40). 

Notation  "P  ,/\  Q"  :=  (andx  P  Q)  (at  level  51,  right  associativity). 

Notation  "P  .\/  Q"  :=  (orx  P  Q)  (at  level  70,  right  associativity). 

Notation  "P  . ->  Q"  :=  (impx  P  Q)  (at  level  100,  right  associativity) 

The  following  auxiliary  definitions  are  straight-forward. 

Definition  Assertion  :=  State  ->  PropX  nil. 


Definition  WordTy  :=  Word  ->  PropX  nil. 

Definition  CdHpSpec  :=  Map  Label  Assertion. 

Definition  DtHpSpec  :=  Map  Label  WordTy. 

Definition  Env  :=  list  (PropX  nil). 

When  weak  update  reference  is  supported,  the  interpretation  of  XCAP  assertions  can 
be  defined  as  the  following. 

Definition  Itp  P  Si  Fi  :=  OK  nil  Si  Fi  P. 


Definition  DH  Si  Fi  H  := 

forall  1  t,  lookup  Fi  1  t  ->  exists  w,  lookup  H  1  w  /\  Itp  (t  w)  Si  Fi. 


Definition  ItP  a  Si  S  := 
match  S  with  (H,  R)  => 

exists  Fi,  exists  HI,  exists  H2, 

disjoint  HI  H2  /\  merge  HI  H2  =  H  /\  Itp  (a  (H1,R))  Si  Fi  /\  DH  Si  Fi  H2 

end. 


Notation  "p  ==>  q"  :=  (forall  Si  S,  ItP  p  Si  S  ->  ItP  q  Si  S) 

(at  level  130,  right  associativity). 

Itp  is  the  interpretation  of  extended  propositions,  defined  using  the  PropX  validity 
below.  ItP  is  the  assertion  interpretation,  as  discussed  in  Section  5.1. 
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Inductive  OK  :  Env  ->  CdHpSpec  ->  DtHpSpec  ->  PropX  nil  ->  Prop  := 


ok_env 

forall  E  Si  Fi  p,  In  p  E 

-> 

OK 

E 

Si 

Fi 

P 

ok_cptr_i 

forall  E  Si  Fi  1  P,  lookup  Si  ] 

P 

-> 

OK 

E 

Si 

Fi 

(cptr  nil 

1  P) 

ok_cptr_e 

forall  E  Si  Fi  1  P  q. 

OK  E  Si  Fi  (cptr  nil  1  P)  -> 
(lookup  Si  1  P  ->  OK  E  Si  Fi 

q) 

-> 

OK 

E 

Si 

Fi 

q 

ok_ref_i  : 

forall  E  Si  Fi  IP,  lookup  Fi  1 

P 

-> 

OK 

E 

Si 

Fi 

(ref  nil 

1  P) 

ok_ref_e  : 

forall  E  Si  Fi  1  P  q, 

OK  E  Si  Fi  (ref  nil  1  P)  -> 
(lookup  Fi  1  P  ->  OK  E  Si  Fi 

q) 

-> 

OK 

E 

Si 

Fi 

q 

ok_prop_i 

forall  E  Si  Fi  (p  :  Prop) ,  p 

-> 

OK 

E 

Si 

Fi 

(«  p  ») 

ok_prop_e 

forall  E  Si  Fi  (p  :  Prop)  q, 

OK  E  Si  Fi  (<<  p  >>)  -> 

(p  ->  OK  E  Si  Fi  q) 

-> 

OK 

E 

Si 

Fi 

q 

ok_and_i 

forall  E  Si  Fi  p  q,  OK  E  Si  Fi 

P  -> 

OK  E  Si  Fi 

q 

-> 

OK 

E 

Si 

Fi 

(p  ,/\  q) 

ok_and_el 

forall  E  Si  Fi  p  q. 

OK  E  Si  Fi  (p  ,/\  q) 

-> 

OK 

E 

Si 

Fi 

P 

ok_and_e2 

forall  E  Si  Fi  p  q. 

OK  E  Si  Fi  (p  ,/\  q) 

-> 

OK 

E 

Si 

Fi 

q 

ok_or_il 

forall  E  Si  Fi  p  q,  OK  E  Si  Fi 

p 

-> 

OK 

E 

Si 

Fi 

(p  A/  q) 

ok_or_i2 

forall  E  Si  Fi  p  q,  OK  E  Si  Fi 

q 

-> 

OK 

E 

Si 

Fi 

(p  A/  q) 

ok_or_e 

forall  E  Si  Fi  p  q  r, 

OK  E  Si  Fi  (p  A/  q)  -> 

OK  (cons  p  E)  Si  Fi  r  -> 

OK  (cons  q  E)  Si  Fi  r 

-> 

OK 

E 

Si 

Fi 

r 

ok_imp_i 

forall  E  Si  Fi  p  q. 

OK  (cons  p  E)  Si  Fi  q 

-> 

OK 

E 

Si 

Fi 

(p  .->  q) 

ok_imp_e 

forall  E  Si  Fi  p  q, 

OK  E  Si  Fi  p  -> 

OK  E  Si  Fi  (p  .->  q) 

-> 

OK 

E 

Si 

Fi 

q 

ok_allx_i 

forall  E  Si  Fi  A 

(P  :  A  ->  PropX  nil) , 

(forall  x,  OK  E  Si  Fi  (P  x)) 

-> 

OK 

E 

Si 

Fi 

(allx  nil 

A  P) 

ok_allx_e 

forall  E  Si  Fi  A  P, 

OK  E  Si  Fi  (allx  nil  A  P)  -> 
forall  B  :  A, 

OK 

E 

Si 

Fi 

(P  B) 

ok_extx_i 

forall  E  Si  Fi  A 

(P  :  A  ->  PropX  nil)  x, 

OK  E  Si  Fi  (P  x) 

-> 

OK 

E 

Si 

Fi 

(extx  nil 

A  P) 

ok_extx_e 

forall  E  Si  Fi  A  P  q, 

OK  E  Si  Fi  (extx  nil  A  P)  -> 
(forall  B  :  A, 

OK  (cons  (P  B)  E)  Si  Fi  q) 

-> 

OK 

E 

Si 

Fi 

q 

ok_allv_i 

forall  E  Si  Fi  A  p, 

(forall  x  :  A  ->  PropX  nil. 

OK  E  Si  Fi  (Subst  nil  A  p  x)) 

-> 

OK 

E 

Si 

Fi 

(allv  nil 

A  p) 

ok_extv_i 

forall  E  Si  Fi  A  p 

(q:  A  ->  PropX  nil) , 

OK  E  Si  Fi  (Subst  nil  A  p  q) 

-> 

OK 

E 

Si 

Fi 

(extv  nil 

A  p) 

ok_mu_i 

forall  E  Si  Fi  A  p  (v:A), 

OK  E  Si  Fi  (Subst  nil  A  (p  v) 

(mu  nil  A  p)) 

-> 

OK 

E 

Si 

Fi 

(mu  nil  A 

p  v) 

112 


Soundness  of  PropX  validity  rules  is  implemented  as  the  following  lemma.  It  takes 


around  4,000  lines  of  Coq  tactics  to  prove  this  theorem. 

Lemma  Validity_Soundness  : 

forall  L  Si  Fi  (p  :  PropX  L) , 

match  L  as  t  return  forall  p  :  PropX  t,  Prop  with 
nil  =>  fun  p  =>  OK  nil  Si  Fi  p  -> 


match  p 

in 

PropX  t  return 

t  =  nil  - 

>  Prop  with 

1  var 

_ 

=>  fun  pf 

=> 

False 

1  lift 

=>  fun  pf 

=> 

False 

1  cptr 

1 

P  =>  fun  pf 

=> 

lookup 

Si 

1  (fun  S  =>  eq_rect  _  (PS)  pf) 

1  ref 

1 

P  =>  fun  pf 

=> 

lookup 

Fi 

1  (fun  S  =>  eq_rect  _  (PS)  pf) 

1  prop  _ 

P 

=>  fun  pf 

=> 

P 

1  andx 

P 

q  =>  fun  pf 

=> 

OK  nil 

Si 

Fi  (eq_rect  p 

_  pf)  /\ 

OK  nil 

Si 

Fi  (eq_rect  q 

-  Pf) 

1  orx 

P 

q  =>  fun  pf 

=> 

OK  nil 

Si 

Fi  (eq_rect  p 

_  pf)  \/ 

OK  nil 

Si 

Fi  (eq_rect  q 

-  Pf) 

1  impx 

P 

q  =>  fun  pf 

=> 

OK  nil 

Si 

Fi  (eq_rect  p 

_  pf)  -> 

OK  nil 

Si 

Fi  (eq_rect  q 

-  Pf) 

1  allx 

A 

P  =>  fun  pf 

=> 

forall 

x, 

OK  nil  Si  Fi  (eq_rect  (P  x)  pf) 

1  extx 

A 

P  =>  fun  pf 

=> 

exists 

x, 

OK  nil  Si  Fi  (eq_rect  (P  x)  pf) 

1  allv 

A 

p  =>  fun  pf 

=> 

forall 

x, 

OK  nil  Si  Fi 

(Subst 

(eq_rect 

-  P  - 

(trans_eq  (eq_app_eq 

-  -  Pf) 

x) 

p  =>  fun  pf 

(sym_eq  (nil 

_app_eq  _)))) 

1  extv 

A 

=> 

exists 

x, 

OK  nil  Si  Fi 

(Subst 

(eq_rect 

-  P  - 

(trans_eq  (eq_app_eq 

-  -  Pf) 

x) 

v  =>  fun  pf 

(sym_eq  (nil 

_app_eq  _)))) 

1  mu 

P 

=> 

OK  nil 

Si 

Fi 

(Subst 

(eq_rect 

_  (P  v)  _ 

(trans_eq  (eq_app_ 

eq  _  _  _  pf) 

(sym_eq 

(nil_app_eq  _)))) 

(mu  nil 

_ 

(fun  v  ; 

=> 

(eq_rect  (P  v) 

_  (eq_app_eq  _  _  _  pf))))) 

end  (refl_equal  _) 

I  _  =>  fun  _  =>  True 
end  p . 

To  allow  more  Prop-like  handling  of  proofs,  we  build  many  tactics  for  PropX  reason¬ 
ing.  Below  are  a  selection  of  them. 
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Definition  okvalid  :=  Validity_Soundness  nil. 


Ltac  des  H 


generalize 

(okvalid 

_  H); 

clear 

H; 

Ltac  dest  H 

:  = 

generalize 

(okvalid 

_  H); 

clear 

H; 

Ltac  destx  H 

v  :  = 

generalize 

(okvalid 

_  H); 

clear 

H; 

Ltac  splitx 
Ltac  leftx 
Ltac  rightx 
Ltac  introx 
Ltac  existsx 
Ltac  introv 
Ltac  existsv 
Ltac  propx 
Ltac  cptrx 


:=  apply 
:=  apply 
:=  apply 
:=  apply 
x  :=  apply 
:=  apply 
a  :=  apply 
:=  apply 
:=  apply 


ok_and_i . 
ok_or_il . 
ok_or_i2 . 
ok_allx_i . 
ok_extx_i  with 
ok_allv_i . 
ok_extv_i  with 
ok_prop_i . 
ok_cptr_i . 


8.2  Implementation  of  XCAP 


intro;  unfold  eq_rect  in  *  |-. 


destruct  1;  unfold  eq_rect  in  *  |-. 


destruct  1  as  [v] ;  unfold  eq_rect  in  * 


x . 


We  implemented  XCAP  inference  rules  as  the  following  inductive  definitions. 
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Inductive  WFiseq  :  CdHpSpec  ->  Assertion  ->  InstrSeq  ->  Prop  := 

I  wfiseq  :  forall  Si  a  c  I  a’ , 

(forall  Si  s,  ItP  a  Si  s  -> 
exists  s  ’  , 

Next  css’  /\  ItP  a’  Si  s’)  -> 

WFiseq  Si  a1  I  ->  WFiseq  Si  a  (iseq  c  I) 

I  wfbgti  :  forall  Si  a  rs  w  1  I  a’  a’  ’  , 

((fun  s  =>  <<  _R  s  rs  <=  w  >>  ./\  a  s)  ==>  a’’)  -> 

((fun  s  =>  <<  _R  s  rs  >  w  »  . /\  a  s)  ==>  a’  )  -> 

lookup  Si  1  a’  -> 

WFiseq  Si  a’ 1  I  ->  WFiseq  Si  a  (bgti  rs  w  1  I) 

I  wf jd  :  forall  Si  a  1  a’ , 

lookup  Si  1  a’  -> 

(a  ==>  a’)  ->  WFiseq  Si  a  (jd  1) 

I  wfjmp  :  forall  Si  a  r, 

(a  ==>  fun  S  =>  extv 


(eq_rect  _  _  (cptr  _  (_R  S  r)  (var  _  _) 

. /\  var  _  _  S) 

(nil_app_eq  _)))  ->  WFiseq  Si  a  (jmp  r) 

I  wfecp  :  forall  Si  a  1  a’  a’ ’  I, 

WFiseq  Si  a’  I  -> 
lookup  Si  1  a’ ’  -> 

((fun  s  =>  cptr  1  a’ 1  . /\  a  s)  ==>  a’)  ->  WFiseq  Si  a  I. 


Inductive  WFcode  :  CdHpSpec  ->  CodeHeap  ->  CdHpSpec  ->  Prop  := 

I  wfcdhp  :  forall  Si  Si’  C, 

(forall  1  a,  lookup  Si’  1  a  -> 

exists  I,  lookup  C  1  I  /\  WFiseq  Si  a  I)  ->  WFcode  Si  C  Si’ 

I  wf link  :  forall  Sil  Si2  Si’l  Si ’2  Cl  C2, 

WFcode  Sil  Cl  Si’l  -> 

WFcode  Si2  C2  Si’ 2  -> 

Map. disjoint  Cl  C2  -> 
subseteq  Sil  (merge  Sil  Si2)  -> 
subseteq  Si2  (merge  Sil  Si2) 

->  WFcode  (merge  Sil  Si2)  (merge  Cl  C2)  (merge  Si’l  Si’2). 

Definition  WFprogram  Si  a  P  :=  match.  P  with  (c,  (s,  i))  => 

WFcode  Si  c  Si  /\  ItP  a  Si  s  /\  WFiseq  Si  a  i 
end. 


Selected  soundness  theorem  and  lemmas  of  XCAP  are  presented  as  follows.  It  takes 
around  700  Coq  tactics  to  prove  these  theorem.  This  confirms  that  XCAP  is  a  lightweight 
framework. 


115 


Lemma  InstrSeqWeakening  : 
forall  Si  Si’  a  a’  I, 

WFiseq  Si  a’  I  ->  subseteq  Si  Si’  ->  (a  ==>  a’)  ->  WFiseq  Si’  a  I. 

Lemma  CodeHeapTyping  : 
forall  C  Si  1  a, 

WFcode  Si  C  Si  ->  lookup  Si  1  a  ->  exists  I,  lookup  C  1  I  /\  WFiseq  Si  a  I. 

Theorem  Soundness  : 

forall  Si  a  P,  WFprogram  Si  a  P  -> 

exists  a’,  exists  P’,  STEP  P  P’  /\  WFprogram  Si  a’  P’. 

8.3  Implementation  of  XCAP86 


XCAP86's  machine  model,  Mini86,  is  quite  different  from  TM  used  in  XCAP.  Its  Coq  im¬ 
plementation  is  complicated  by  new  details  such  as  byte-addressed  word-aligned  mem¬ 
ory,  fixed  machine  word  size,  and  machine  instruction  decoding.  For  example,  the  follow¬ 
ing  are  the  macros  to  test  if  a  byte  or  word  is  stored  in  the  memory  (To  keep  our  machine 
model  close  to  TM,  the  memory  is  modeled  as  a  mapping  from  aligned  addresses  to  ma¬ 
chine  words.) 


Definition  byte  h  1  := 

match  (Z_eq_dec  (1  mod  4)  0)  with 
I  left  _  =>  match  (h  1)  with 

I  Some  w  =>  Some  (w  mod  256) 

I  None  =>  None 
end 

I  _  =>  match  (Z_eq_dec  (1  mod  4)  1)  with 

I  left  _  =>  match  (h  (1-1))  with 

I  Some  w  =>  Some  ((w  /  256)  mod  256) 

I  None  =>  None 
end 

I  _  =>  match  (Z_eq_dec  (1  mod  4)  2)  with 

I  left  _  =>  match  (h  (1-2))  with 

I  Some  w  =>  Some  ( (w  /  65536)  mod  256) 

I  None  =>  None 

end 

I  _  =>  match  (h  (1-3))  with 

I  Some  w  =>  Some  ( (w  /  65536)  /  256) 

I  None  =>  None 
end 

end 


end 


end. 
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Definition  dword  h  1  w  :=  byte  hi  =  Some  (w  mod  256) 

/\  byte  h  (1+1)  =  Some  (w  /  256  mod  256) 

/\  byte  h  (1+2)  =  Some  (w  /  65536  mod  256) 

/\  byte  h  (1+3)  =  Some  (w  /  65536  /  256) . 

We  carefully  designed  Mini86  and  its  implementation  so  that  they  stay  as  close  to  TM 
as  possible.  For  example,  below  are  selected  implementations  details  of  Mini86,  which 

look  similar  to  TM's  in  Section  2.2. 

Inductive  Next  :  Instr  ->  State  ->  State  ->  Prop  := 

I  stp_add  :  forall  r  o  H  R  F  R’  F’, 

Dword  (R  r  +  Ro  R  o)  -> 
uR  R  R:  r  (R  r  +  Ro  R  o)  -> 

CalcF  F’  (R  r  +  Ro  R  o)  -> 

Next  (add  r  o)  (H,  R,  F)  (H,  R’ ,  F’) 

I  stp_mov  :  forall  r  o  H  R  F  R’ , 

uR  R  R’  r  (Ro  R  o)  -> 

Next  (mov  r  o)  (H,  R,  F)  (H,  R’ ,  F) 

I  stp_movrm  :  forall  r  d  H  R  F  w  R’ , 

lookup  H  (Ra  R  d)  w  -> 
uR  R  R:  r  w  -> 

Next  (movrm  r  d)  (H,  R,  F)  (H,  R’ ,  F) 


Inductive  STEP  :  Program  ->  Program  ->  Prop  := 

I  stp_iseq  :  forall  H  R  F  H’  R’  F’  pc  c  npc , 

Dc  H  pc  c  npc  -> 

Next  c  (H,  R,  F)  (H>  ,  R’ ,  F’)  -> 

STEP  ((H,  R,  F),  pc)  (0T,  R’  ,  F’),  npc) 

I  stp_jmp  :  forall  o  H  R  F  pc  npc, 

Dc  H  pc  (jmp  o)  npc  -> 

STEP  ((H,  R,  F),  pc)  ((H,  R,  F) ,  Ro  R  o) 

I  ...  . 

Other  than  the  difference  in  machine  model,  XCAP86  also  mainly  differs  in  instruction- 
level  inference  rules. 


117 


Inductive  WFiseq  :  CdHpSpec  ->  Assertion  ->  InstrSeq  ->  Prop  := 
I  wfiseq  :  forall  Si  a  c  I  a’ , 


1  wfjcc  : 

(a  ==>  (fun  s  =>  Ex  s ’  . 

<<Next  c  s  s’>>  ,/\  a’  s’))  -> 

WFiseq  Si  a’  I  ->  WFiseq  Si  a  (iseq  c  I) 

:  forall  Si  a  cc  f  I  a’  a’  ’  , 

((fun  s  =>  «~(Fcc  (_F  s)  cc)»  ./\  a  s)  ==>  a’’)  -> 

((fun  s  =>  «Fcc  (_F  s)  cc>>  ,/\  a  s)  ==>  a’)  -> 

1  wfjmpi  : 

lookup  Si  f  a’  -> 

WFiseq  Si  a1 ’  I  ->  WFiseq  Si  a  (iseq  (jcc  cc  f)  I) 

:  forall  Si  a  f  a' , 
lookup  Si  f  a'  -> 

(a  ==>  a’)  ->  WFiseq  Si  a  (instr  (jmp  (word  f))) 

1  wfjmpr  : 

:  forall  Si  a  r, 

(a  ==>  fun  S  =>  extv 

(eq_rect  _  _  (cptr  _  (_R  S  r)  (var  _  _) 

./\  var  _  _  S) 

1  wfcalli  : 

_  (nil_app_eq  _))) 

->  WFiseq  Si  a  (instr  (jmp  (reg  r))) 

:  forall  Si  a  f  fret  a’ , 

1  wfcallr  : 

lookup  Si  f  a'  -> 

(a  ==>  (fun  s  =>  Ex  s’. 

<<Next  (push  (word  fret))  s  s’>> 

./\  a’  s’)) 

->  WFiseq  Si  a  (instr’  (call  (word  f))  fret) 

:  forall  Si  a  r  fret, 

(a  ==>  (fun  S  =>  extv 

(eq_rect  _  _  (cptr  _  (_R  S  r)  (var  _  _) 

./\  Ex  s’.  <<Next  (push  (word  fret))  S  s’>> 

. /\  var  s ’ ) 

1  wfret  : 

_  (nil_app_eq  _)))) 

->  WFiseq  Si  a  (instr’  (call  (reg  r))  fret) 

:  forall  Si  a, 

1  wfecp 

(a  ==>  (fun  S  =>  Ex  fret. 

<<lookup  (_H  S)  (_R  S  esp)  fret>> 

./\  extv 

(eq_rect  _  _  (cptr  _  fret  (var  _  _) 

,/\  Ex  s’.  <<Next  pop’  S  s’» 

. /\  var  s ’ ) 

_  (nil_app_eq  _)))) 

->  WFiseq  Si  a  (instr  ret) 

:  forall  Si  a  f  a’  a’’  I, 

WFiseq  Si  a’  I  -> 
lookup  Si  f  a’ ’  -> 

((fun  s  =>  cptr  f  a’ ’  ./\  a  s)  ==>  a’)  ->  WFiseq  Si  a  I. 

The  implementation  of  Mini86  takes  about  400  lines  of  Coq  code.  The  implementation 
of  XCAP86  meta  theory  takes  about  1,000  lines  of  Coq  code. 
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8.4  Implementation  of  MTH 


Every  MTH  module  is  specified  and  verified  separately  from  its  clients.  During  the  cer¬ 
tification  of  MTH,  we  collected  a  large  number  of  lemmas,  including  some  on  generic 
separation-logic  reasoning  and  others  on  common  code  patterns.  Our  Coq  implemen¬ 
tation  consists  of  approximately  34,000  lines  of  Coq  code  (about  5,000  lines  are  common 
lemmas,  3,000  lines  are  for  the  queue  module,  8,000  lines  are  for  the  machine  context  mod¬ 
ule,  and  18,000  lines  are  for  the  threading  module).  The  full  compilation  of  XCAP86  and 
MTH  implementation  in  Coq  (proof-script  checking  and  proof-binary  generation)  takes 
about  4  hours  on  an  Intel  Pentium  M  1.6Ghz  CPU  with  2GB  memory. 

The  development  of  the  code  took  nearly  six  person-month.  There  are  several  reasons 
for  the  large  proof  size.  First  of  all,  this  is  the  first  time  we  are  doing  this  kind  of  realistic 
proof,  so  a  lot  of  infrastructural  code  and  experience  need  to  be  developed  and  learned. 
For  example,  the  first  procedure  we  certified,  swapcontext(),  took  one  person-month  and 
5,000  lines  of  Coq  code,  even  though  it  consists  of  only  19  lines  of  assembly  code.  Sec¬ 
ond,  the  relatively  low  level  of  proof  reuse  caused  much  redundancy.  The  third  reason  is 
the  complexity  of  x86  machine,  where  features  such  as  finite  integer  and  byte-addressed 
word-aligned  memory  are  not  support  very  well  in  Coq  yet.  Nevertheless,  the  biggest 
reason,  we  believe,  is  the  complexity  of  the  actual  machine  code,  which  is  obvious  based 
on  the  discussions  in  the  previous  chapter. 

For  example,  the  machine  context  data  type  in  Section  7.2  is  implemented  as  the  fol¬ 
lowing,  which  is  more  complex  than  what  its  meta  presentation  looks  like. 
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Definition  mctx_t  L  aenv  mctx  :  Heap  ->  PropX  L  := 
fun  H  => 

Ex  retv,  bx,  cx,  dx,  si,  di,  bp,  sp,  ret. 

star  (ptolist  _  mctx  (retv : :bx : : cx: : dx : : si : : di : :bp : : sp : :nil) ) 

(star  (pto  _  sp  ret) 

(fun  H  =>  extv  _  _  (eq_rect 
(Lift  _  _  (var  tO  _  H) 

,/\  codeptr  _  ret 

(fun  S’  =>  match  S’  with  ((H’,R’),F’)  in 

reg6  _  bx  cx  dx  si  di  bp  (sp+4)  R’  . /\  «  R’  eax  =  retv» 

,/\  star  (fun  H  =>  Shift 

(eq_rect  _  _  (aenv  H)  _  (app_nil_eq  _))  _) 
(star  (ptolist  _  mctx  (retv : :bx : : cx : : dx : : si : : di : :bp : : sp : : nil) ) 
(star  (pto  _  sp  ret) 

(fun  H  =>  Lift  _  _  (var  tO  _  H)))) 

H’ 


end) ) 


H. 


_  (nil_app_eq  _)))) 


On  the  other  hand,  since  we  have  used  a  lot  of  abstraction  and  composition  in  the 
verification  and  implementation,  we  are  still  able  to  achieve  very  abstract  and  modular 
specifications  and  reasoning,  such  as  the  thread  yielding  function  interface  shown  below. 


Definition  Amth_yield 
Pre:  star  (Imem  _) 

Post:  star  (Imem  _) 


:  Assertion 
(Imth  _) ; 
(Imth  _)}. 


: =  Fn6  {Aux 


Local  :  [12]  ; 
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Chapter  9 


Conclusion  and  Future  Work 

9.1  Conclusion 

The  formal  establishment  of  low-level  system  code  safety  poses  great  challenges  to  ex¬ 
isting  language-based  security  methods.  In  particular,  generating  proof-carrying  code 
for  realistic  machine  binary  requires  a  verification  framework  that  is  both  expressive  and 
modular.  Previously,  neither  traditional  type  systems  nor  Hoare-logic  systems  can  achieve 
both  of  these  goals  without  comprise.  Type  systems  in  general  lacks  support  of  general 
logic  predicate,  while  ordinary  logic  assertions  can  not  modularly  talk  about  higher-order 
programming  concepts  such  as  embedded  code  pointers. 

In  this  dissertation,  we  propose  a  hybrid  approach  to  achieve  modular  and  expressive 
machine  code  verification.  By  combining  the  general  logic  and  semantic  subsumptions 
with  syntactic  type-like  constructs  and  inference  rules,  our  new  framework,  XCAP,  can 
be  used  to  write  program  specification  in  arbitrary  logical  predicates,  in  which  higher- 
order  features  such  as  embedded  code  pointers,  impredicative  polymorphisms,  recursive 
specifications,  and  weak  update  references  can  be  expressed  as  primitive  propositions. 
Thus,  XCAP  achieves  the  expressive  power  of  logic-based  approaches  and  the  modularity 
of  type-based  approaches. 

XCAP  is  not  an  isolated  result.  It  can  be  used  as  a  target  of  existing  certifying  corn- 
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piler,  since  there  is  a  straight-forward  type-preserving  translation  from  a  typed  assembly 
language  to  XCAP.  The  interaction  of  TAL  and  XCAP  code  is  very  flexible,  as  the  transla¬ 
tion  is  essentially  a  shallow  embedding  of  TAL  in  XCAP's  assertion  language,  PropX.  For 
application  and  system  code  written  in  type-safe  languages,  XCAP  is  a  good  platform  for 
these  code  to  interoperate  with  each  other,  as  well  as  other  certified  system  kernel  module. 

The  most  important  goal  for  XCAP  is  to  support  direct  verification  of  realistic  system 
kernel  assembly  code  with  the  help  of  an  interactive  proof  assistant.  XCAP  is  ported  to 
XCAP86,  with  a  realistic  machine  model  following  the  x86  architecture.  We  show  how 
to  use  XCAP86  to  certify  a  mini  thread  library,  which  could  serve  as  a  basis  for  realistic 
certified  system  kernel.  Such  kind  of  code  is  not  certifiable  with  traditional  type  safe 
languages,  thus  our  verification  is  the  first  of  this  kind. 

One  key  aspect  of  the  XCAP  framework  is  mechanization.  Not  only  are  the  machine 
model,  specification  languages,  and  proof  of  assembly  programs  fully  mechanized  in  the 
Coq  proof  assistant,  but  the  entire  meta  theory  of  XCAP  and  its  various  extensions  are 
fully  implemented  in  Coq  as  well.  In  the  end,  the  only  things  that  need  to  be  trusted  by 
the  programmers  and  users  are  merely  the  machine  model,  mathematical  logic,  and  a  tiny 
proof-checker. 

In  summary,  XCAP  is  a  simple,  general,  expressive,  and  modular  framework  for  veri¬ 
fication  of  realistic  machine  code  found  in  both  application  and  system  programs. 


9.2  Trusted  Computing  Base 

Given  the  mixed  presentation  of  the  theoretical  framework  and  mechanized  implemen¬ 
tation  in  the  previous  chapters,  it  may  not  be  obvious  what  exactly  are  trusted  and  un¬ 
trusted  for  XCAP  and  its  applications.  In  this  section  we  discuss  the  trusted  computing 
base  (TCB)  from  the  point  of  view  of  a  programmer. 


122 


Trusted:  meta  logic.  To  do  any  formal  reasoning,  the  programmer  has  to  choose  a  (mech¬ 
anized)  meta  logic,  and  trust  it  with  respect  to  his  intuition,  i.e.,  agree  with  the  represen¬ 
tations  and  reasoning  in  it.  In  our  case,  the  variant  of  Calculus  of  Inductive  Constructions 
(CiC),  a.k.a.,  higher-order  predicate  logic  with  inductive  definitions,  is  the  mechanized 
meta  logic  theory  that  needs  to  be  trusted.  The  programmer  should  treat  this  logic  as  a 
consistent  one.  Yet  its  consistency  is  not  provable  inside  itself.  In  practice,  it  is  usually  not 
a  big  concern,  as  the  meta  theory  of  the  logic  has  been  published  and  can  be  examined  by 
any  logicians. 

Trusted:  machine  model.  First  of  all,  the  programmer  has  to  trust  the  mathematical 
modeling  of  the  actual  hardware,  namely,  the  CPU  and  the  memory.  The  machine  rep¬ 
resentation  on  paper  and  encoding  in  Coq  are  merely  symbols,  while  the  actual  compu¬ 
tation  is  a  physical  process.  Without  including  formal  hardware  verification  results,  it  is 
impossible  to  prove  the  correspondence  between  the  symbols  and  the  hardware  state.  In 
practice,  it  is  usually  not  a  concern  though,  as  the  hardware  specifications  are  publically 
available  and  considered  correct  in  general. 

Trusted:  proof  checker.  In  terms  of  mechanization,  the  programmer  needs  to  have  a 
proof  checker  to  mechanically  check  the  validity  of  proofs  with  respect  to  specifications. 
The  proof  checker  has  to  be  trusted  unless  it  is  verified  again  using  some  other  formal 
method  (which  again  will  have  the  question  of  TCB).  Note  that  the  proof  checker  is  not 
equal  to  the  entire  Coq  proof  assistant;  only  a  small  part  of  Coq  does  the  job  of  proof 
checking.  The  majority  of  Coq  source  code,  such  as  those  dealing  with  proof  searching, 
do  not  need  to  be  trusted.  This  is  similar  to  the  "certifying  compiler  "  concept.  Although 
we  do  not  have  a  stand-alone  proof  checker  for  CiC,  building  one  should  not  take  more 
than  a  few  thousand  lines  of  code.  One  easy  way  to  raise  assurance  of  the  proof  checker  is 
to  independently  develop  multiple  checkers.  This  way,  even  if  each  checker  has  bugs  that 
occur  20%  of  the  time,  the  chance  of  a  faulty  proof  passing  three  checkers  is  less  than  1%. 
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Untrusted:  PropX  and  XCAP  theory.  Since  the  entire  PropX  and  XCAP  meta  theory 
have  been  mechanized  and  proved  consistent  inside  Coq,  they  do  not  need  to  be  trusted  at 
all.  As  shown  by  the  various  expansions  done  in  this  dissertation,  as  long  as  the  expanded 
framework  is  proved  sound  in  Coq,  these  extensions  are  safe. 

Trusted:  program  specifications  and  safety  polices.  Whether  the  program  specifica¬ 
tions  and  safety  polices  are  trusted  or  not  is  perhaps  the  most  confusing  question.  The 
programmer  has  to  realize  that,  in  the  end,  he  has  to  trust  that  the  program  specifica¬ 
tions  do  reflect  what  is  expected  of  the  program's  behavior.  However,  for  traditional  type 
systems,  one  often  has  to  ask  "what  kind  of  properties  are  actually  supported".  This  is  be¬ 
cause  there  is  a  gap  between  program  specifications — types — and  the  meta  logical  safety 
polices.  In  other  words,  what  a  programmer  sees  (types)  is  not  exactly  what  he  gets  (safety 
policy).  He  has  to  trust  two  things:  (1)  the  program  specification  reflects  the  safety  policy; 
and  (2)  the  safety  policy  is  what  he  wants. 

For  XCAP,  however,  we  support  WYSWYG  (What  You  See  is  What  You  Get),  as  the 
program  specifications  are  written  in  logic  formulas.  The  code  heap  specification  con¬ 
tains  the  safety  polices  at  each  key  program  point.  (Strictly  speaking,  XCAP  specifications 
are  not  meta  logic  formulas,  as  they  may  contain  PropX  syntactic  constructs  such  as  cptr; 
however,  the  soundness  theorem  of  PropX  interpretation  guarantees  that  PropX  level  con¬ 
structors  and  quantifiers  can  be  treated  as  meta  logic  ones.)  Thus  it  is  meaningless  to  ask 
"what  kind  of  properties  are  actually  supported",  as  all  possible  state-based  safety  policies 
definable  in  CiC  are  supported  in  XCAP.  When  we  refer  to  an  XCAP  program  specifica¬ 
tion  as  "trusted",  we  only  mean  that  we  believe  the  meta  logic  safety  policy  (same  as  the 
program  specification)  is  what  we  really  want. 

Untrusted:  safety  proof.  Once  the  program  specification  is  set,  the  safety  proof  can  be 
constructed  through  many  different  ways,  such  as  theorem  provers,  interactive  proof 
assistants,  and  certifying  compilers.  None  of  these  details  matters,  though,  as  the  pro- 
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grammer  does  not  need  to  trust  these  proof — either  they  are  correct  and  accepted  by  the 
checker,  or  they  are  incorrect  and  rejected  by  the  checker. 

Based  on  the  above  discussions,  it  is  clear  that  the  trusted  computing  base  for  XCAP 
is  really  small.  In  the  author's  opinion,  the  only  further  reducible  part  of  the  TCB  is  the 
proof  checker,  which  can  always  be  replaced  by  smaller  and  smarter  implementations,  so 
that  they  can  be  verified  by  hand. 


9.3  Comparison  with  the  Indexed  Approach 

One  line  of  work  closely  related  to  the  approach  in  this  dissertation  is  the  "index-based 
semantic  model"  approach  [6, 18, 3, 8, 9, 2,  56, 10].  In  this  section  we  refer  to  that  approach 
as  the  indexed  approach. 

The  indexed  approach  and  XCAP  share  a  lot  of  similarities  as  both  of  them  belong  to 
the  foundational  proof-carrying  code  architecture.  Both  are  based  on  mechanized  meta 
logics.  While  XCAP  uses  higher-order  predicate  logic  with  inductive  definitions,  the  in¬ 
dexed  approach  has  used  the  same  higher-order  predicate  logic  as  well  as  another  higher- 
order  logic.  Both  want  to  produce  foundational  proof  for  well-typed  programs  and  face 
the  same  problem  of  how  to  modularily  express  higher-order  type-oriented  features  such 
as  embedded  code  pointers,  general  references,  impredicative  polymorphisms,  and  recur¬ 
sive  types  in  the  meta  logic. 

The  theoretical  difference  between  the  indexed  approach  and  the  XCAP  approach  is 
mainly  on  whether  to  use  an  extra  natural  number  as  "index"  in  "world"  and  judgments, 
or  to  use  an  extra  thin  layer  of  syntax  and  interpretation  to  solve  the  above  problem.  In 
the  most  recent  version  of  the  indexed  approach,  Appel  et  al  [10]  proposed  a  new  modal 
model  for  expressing  recursive  and  impredicative  quantified  types  with  mutable  refer¬ 
ence.  Their  method  uses  a  Kripke  semantics  of  the  Godel-Lob  logic  of  provability.  To  sup¬ 
port  mutable  reference,  they  include  the  memory  mapping  information  in  the  "world". 

At  the  top  level,  the  difference  seems  to  be  rather  big  considering  the  similarity  be- 
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tween  the  two  approaches.  There  are  several  reasons  for  the  different  solutions  the  two 
approaches  have  reached  as  of  today. 

For  the  indexed  approach,  they  initially  chose  to  work  upon  a  logic  framework  (LF), 
formalize  the  meta  logic  (HOL)  in  it,  and  build  semantic  models  for  types  in  HOL.  This 
approach  turned  out  to  be  quite  heavyweight,  as  one  has  to  first  build  an  entire  mecha¬ 
nized  meta  logic  through  deep  embedding.  Even  that,  since  there  is  no  built-in  inductive 
definition  in  the  meta  logic,  one  has  to  use  Godel  numbers  to  simulate  simple  inductive 
definitions.  While  for  the  CAP/XCAP  approach,  the  work  has  been  based  on  CiC  /  Coq, 
which  act  as  both  a  logic  framework  and  a  meta  logic  framework  (through  shallow  em¬ 
bedding),  and  have  built-in  support  of  inductive  definitions.  This  allows  light-weight 
implementation,  as  shown  by  the  hundreds  of  lines  of  code  for  CAP  and  the  thousands 
of  lines  of  code  for  PropX  and  XCAP  Later  on,  the  indexed  approach  has  switched  to  use 
CiC/ Coq  and  can  now  offload  the  burden  of  building  meta  logics  and  simulating  induc¬ 
tive  definitions.  Since  this  switch  is  relatively  new,  it  is  still  too  early  to  make  detailed 
comparison  between  the  implementations  of  the  latest  indexed  approach  and  XCAP. 

One  major  reason  is  the  different  guarantee  of  these  two  approaches.  For  XCAP,  it  is 
designed  to  support  more  than  "type  safety"  at  each  program  point.  The  code  heap  spec¬ 
ification  specifies  the  safety  policy  in  general  logic  predicates  (safety  policy),  and  is  com¬ 
pletely  customizable.  Meta  theory  of  XCAP  guarantees  that  these  safety  policies  are  actu¬ 
ally  observable.  While  for  the  indexed  approach,  the  definition  of  "codeptr"  has  always 
been  based  on  a  non-stuckness  safety  (when  the  program  jumps  to  an  indirect  address, 
the  meta  theory  can  only  guarantee  that  the  future  execution  of  the  program  will  never 
get  stuck).  Thus,  there  the  safety  guarantee  is  more  like  the  traditional  notion  of  type 
safety  and  memory  safety.  It  remains  unclear  how  to  change  the  definition  of  "codeptr" 
in  order  to  support  customizable  and  observable  safety  policies  without  rebuilding  the 
meta  theory  of  the  indexed  approach. 

Another  reason  is  the  difference  between  the  verification  targets  of  these  approaches. 
XCAP  is  designed  to  support  direct  verification  of  assembly  programs  with  non-trivial 
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properties  not  expressible  in  traditional  types.  Besides  the  examples  discussed  in  this 
dissertation,  various  examples  of  CAP/XCAP  programs  have  been  mechanically  certi¬ 
fied  [62,  64,  20, 21, 19].  While  the  indexed  approach  has  been  focusing  on  type-preserving 
compilations  from  high-level  languages,  thus  having  few  applications  of  direct  verifica¬ 
tion  at  assembly  level  now.  It  important  to  note  that  the  XCAP  approach  also  fits  into  the 
type-preserving  compilation  process,  as  shown  by  the  previous  chapters. 

We  believe  that  both  the  indexed  approach  and  the  XCAP  approach  have  a  long  way  to 
go  before  reaching  a  fully  practical  FPCC  framework.  There  are  recent  trends  which  show 
the  possibility  of  these  two  approaches  meeting  and  merging  in  the  future  development. 

9.4  Future  Work 

Given  the  comprehensive  nature  of  the  XCAP  framework,  there  can  be  many  possible  fu¬ 
ture  work  on  type  theory,  logic  theory,  verification  framework  and  tools,  certifying  com¬ 
pilers,  safe  languages,  certified  software  components,  and  software  security. 

General  support  of  higher-order  logic  specifications  One  observation  from  the  hybrid 
type/logic  approach  being  used  in  XCAP  is  that,  although  it  currently  requires  two  dif¬ 
ferent  forms  of  syntactic  higher-order  specifications,  for  code  pointer  and  data  pointer, 
respectively,  there  is  great  similarity  in  their  formation,  interpretation,  and  usage.  One 
idea  is  to  investigate  if  there  is  any  profound  relationship  between  them,  and  hopefully  to 
find  out  a  more  general  way  to  describe  higher-order  logic  specifications.  The  intuition  is 
to  build  a  PropX  level  facility  whose  role  and  functionality  is  similar  to  the  inductive  defi¬ 
nition  facility  in  Prop.  However,  that  will  raise  the  question  of  what  exactly  the  additional 
layer  of  syntax  does,  which  we  do  not  have  a  crystal  clear  understanding  yet.  The  result 
here  could  be  very  useful  for  specification  and  verification  of  synchronization  primitives 
and  garbage  collection. 
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Integrating  logic  specifications  into  type  systems  A  different  angle  to  view  the  frame¬ 
work  is  to  keep  existing  type  systems  and  add  logic-based  specifications  into  them  for  the 
additional  expressive  power.  There  are  already  some  recent  works  along  this  line.  How¬ 
ever,  the  goal  here  is  not  to  define  one  or  a  few  particular  logic-enriched  type  systems,  but 
to  develop  a  systematic  method  to  inject  (partial)  logic-power  into  existing  type  systems. 
Hopefully,  the  effort  that  is  needed  to  enhance  existing  typed  codes  safety  guarantee  will 
then  be  much  less. 

Infrastructure  support  for  logic-based  verification  This  part  includes  the  selection,  eval¬ 
uation,  and  potentially  development  of  mathematical  logic,  binary  format,  concrete  syn¬ 
tax,  proof  checker,  theorem  prover,  proof  assistant,  as  well  as  the  optimization  and  deliv¬ 
ery  of  proof.  Another  important  long-term  effort  will  be  on  building  up  proof  libraries 
and  macros  that  can  be  reused.  This  includes  machine  architecture,  mathematic  theory, 
type  theory,  logic  theory,  proof-searching  tools,  proof-abstraction  tools,  etc. 

Compare  various  works  on  type/logic  theory  The  integration  of  type  and  logic  power 
into  a  formal  system  has  been  an  active  area  in  the  past  few  years.  Other  than  the  works 
on  CAP/XCAP,  there  are  works  such  as  Princetons  indexed  model  for  types,  Harvards  hy¬ 
brid  type/logic  system,  etc.  Investigating  these  works  and  conducting  an  comprehensive 
comparison  of  them  can  be  useful  and  might  yield  interesting  results. 

General  memory  management  Memory  management  has  been  active  field  in  the  past 
decades.  In  type  system  world,  there  are  regions,  linear  types,  stack  types,  etc .;  while  in 
the  logic  system  world,  there  are  separation  logic,  BI  logic,  state  logic,  CAP/XCAP,  etc. 
Apart  from  the  specific  research  on  certifying  garbage  collection,  it  will  be  interesting  to 
explore  the  more  general  memory  management  models  in  the  logic-based  context.  For 
example,  it  might  be  eventually  possible  to  let  users  mix  the  usage  of  "managed"  and 
"unmanaged"  data  pointers  and  even  do  intensional  analysis  of  the  kind  of  data  pointers. 
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C-level  logic-based  language  To  write  system  components  in  a  safe  language,  assembly 
level  is  apparently  too  low,  while  high  level  languages  might  be  a  bit  too  high  for  some 
cases,  especially  for  legacy  systems.  The  major  technical  gap  between  assembly  and  C  lies 
in:  1)  C  stack  abstraction;  2)  register  allocation;  3)  specification  of  complex  control  flow; 
and  4)  preservation  after  compiler  optimization.  As  the  first  step,  4)  could  be  ignored  or 
naively  handled,  since  it  belongs  to  the  more  general  question  of  the  interaction  between 
logic-based  specification  and  type-based  compilation. 

Dynamic  code  generation  /  loading  /  linking  As  a  common  runtime  feature,  dynamic 
code  generation,  loading,  and  linking  are  difficult  to  establish  their  safety,  which  are  cru¬ 
cial  for  extensible  OS  and  other  software.  Dynamic  linking  for  type-safe  code  has  been 
relatively  clear  by  now.  However,  with  components  such  as  runtime  being  certified  using 
logic-based  approach,  how  safe  linking  can  be  automatically  and  dynamically  carried  out 
is  still  unclear.  The  most  extreme  case  will  be  self-modifying  code. 

Binary  compatibility  for  certified  and  legacy  code  One  possible  and  interesting  ques¬ 
tion  to  ask  is  whether  both  certified  and  legacy  code  can  be  compatible  with  each  other. 
There  are  two  scenarios.  The  first  is  to  have  certified  component  being  deployed  in  a 
legacy  system,  knowing  that  internally  the  component  should  not  contain  any  bug,  to 
increase  the  overall  dependability  of  systems,  as  well  as  to  help  debugging  other  legacy 
components.  This  is  relatively  easy  to  do.  The  second  scenario  is  to  have  certified  run¬ 
time  create  protected  virtual  machine  to  load  and  run  uncertified  legacy  code,  and  enforce 
strict  check  upon  its  interface,  thus  achieving  a  safe  and  legacy-friendly  system.  Commu¬ 
nications  between  certified  and  legacy  code  in  such  systems  will  be  interesting,  too. 

BIOS  /  firmware  /  boot  loader  No  matter  how  the  OS  and  software  stack  are  verified, 
the  layer  between  software  and  the  actual  "safe"  hardware,  however  thin  it  is,  is  still  a 
major  venerable  part  of  the  entire  system.  Given  the  ability  to  update  firmware  in  most  of 
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the  modern  computing  devices,  it  is  difficult  to  maintain  the  system  integrity.  Very  likely, 
emerging  security  features  such  as  TPM  and  DRM  will  also  require  safety  guarantees  of 
firmware  to  prevent  them  from  being  compromised  by  all  possible  software-based  attacks. 
These  code  are  suitable  for  the  low-level  logic-based  verification.  Also,  there  are  many 
interesting  non-safety  properties  for  these  code.  For  example,  for  a  firmware,  one  of  the 
most  important  features  is  that  it  will  allow  future  update  what  so  ever.  It  is  interesting  to 
certify  this  particular  property  in  the  case  of  power  loss  during  an  update. 

Preemptive  threading  (interrupts,  I/O,  etc.)  In  the  work  on  verifying  threading  in  this 
dissertation,  as  there  are  no  interrupts,  only  co-operative  non-preemptive  scheduling  is 
supported.  One  argument  is  that  preemptive  scheduling  can  be  treated  as  a  special  case 
of  non-preemptive  threading,  by  inserting  a  virtual  yield  instruction  between  every  in¬ 
struction  that  has  the  interrupt  bit  enabled.  It  will  be  interesting  to  see  what  kind  of 
re-structuring  is  necessary  to  make  the  specification  and  proof  reasonably  simple.  1/ O 
will  be  then  meaningful  to  support  with  the  presence  of  hardware  interrupts. 

Device  driver  Following  up  work  will  naturally  be  device  drivers,  which  currently  are 
either  unsafe  (Windows)  or  restricted  (Singularity).  The  vision  is  that,  even  for  device 
drivers  as  complex  as  self-modifying  ones,  they  can  indeed  be  certified  without  any  com¬ 
promise.  Properties  such  as  temporal  ones  might  need  to  be  introduced  here  if  correctness 
is  a  concern.  Domain-specific  type/logic  languages  might  be  defined  to  utilize  the  com¬ 
monality  of  device  drivers.  Partial  correctness  and  simple  liveness  properties  might  need 
insights  from  existing  work  on  device-driver  verification,  such  as  model  checking. 

Garbage  collectors  It  is  expected  that  verification  of  partial-correctness  of  a  garbage  col¬ 
lection  process  requires  more  than  the  plain  type  safety  provided  by  typical  typed  lan¬ 
guages.  Under  the  hood,  one  major  problem  for  verification  of  garbage  collection  is  that 
traditionally  we  do  not  know  how  to  flexibly  describe  and  cast  between  both  strong  and 
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weak  update  reference  cell,  as  well  as  any  reference  cell  with  mixed  properties  between 
strong  and  weak  update,  e.g.,  a  reference  cell  with  at  most  n  alias. 

High-level  logic-based  language  It  may  be  desirable  to  write  the  majority  of  the  sys¬ 
tem  kernel  and  service  in  high-level  languages.  It  will  be  interesting  to  discover  how  to 
1)  increase  the  expressive  power  of  specification  languages  so  more  advanced  code  and 
properties  can  be  included;  2)  increase  the  level  of  assurance  by  using  sound  logic  and 
checker;  3)  integrate  the  work  with  other  levels  of  logic-based  verification,  such  as  those 
used  by  runtime. 

Synchronization  primitives  (mutex,  channel,  etc.)  In  the  work  on  verifying  thread¬ 
ing  in  this  dissertation,  only  basic  services  such  as  creation,  yielding,  and  termination 
of  threads  are  supported.  However,  in  practice,  the  most  interesting  feature  of  thread  li¬ 
braries  for  concurrent  programming  is  the  set  of  synchronization  primitives  it  provides. 
Which  set  of  primitives  to  support  and  how  they  are  implemented  depends  heavily  on 
the  concurrent  programming  model,  machine  mode,  requirement  on  throughput  and  re¬ 
sponse  time,  as  well  as  the  external  module  interface  to  be  used  together  with  the  library. 
The  work  will  not  only  yield  a  set  of  certified  implementations  of  synchronization  prim¬ 
itives,  but  also  track  down  the  precise  interfaces  of  them,  which  will  be  interesting  by 
themselves.  It  might  also  be  connected  to  existing  works  on  different  synchronization  and 
communication  methods,  such  as  TLA,  allowing  us  to  do  an  exact  comparison  of  differ¬ 
ent  concurrency  models  and  potentially  make  code  that  is  based  on  different  concurrency 
models  work  together. 

Security  properties  As  an  important  feature  of  system  APIs,  security  features  and  the 
properties  they  guarantee  have  traditionally  been  enforced  using  either  dynamic  machine 
semantics  or  static  semantics  of  security  types.  With  the  runtime  and  other  kernel  service 
being  certified  with  logic  specifications,  it  is  possible  to  use  logic  formulas  to  describe 
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security  policies,  thus  allowing  security  guarantees  that  are  much  more  flexible. 

Logic  specifications  in  certifying  compiler  Even  if  we  have  a  higher-level  language 
with  logic  specifications,  right  now  it  is  unclear  how  it  would  fit  into  the  certifying  com¬ 
piler.  Once  decidable  type  checking  and  typing  derivation  are  replaced  by  logic  proofs, 
the  optimization  process  will  lose  the  crucial  structural  information  it  need  to  transform 
the  proof.  On  the  other  hand,  the  ability  to  use  arbitrary  logic  specifications  during  the 
compilation  process  might  eventually  provide  more  expressive  power  on  the  kinds  of 
optimizations  supported  comparing  with  the  traditional  type-preserving  compilation  ap¬ 
proach,  thus  producing  better  optimized  certifying  compiler. 
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Appendix  A 


PropX  Validity  Soundness  Proof 


In  this  section  we  give  the  proof  structure  for  the  soundness  of  PropX  validity  rules,  as 
introduced  in  Section  4.1,  Section  4.3,  Section  5.1,  and  Section  6.2.  To  avoid  confusions, 
we  first  present  the  complete  PropX  definition  in  Figure  A.l  and  the  complete  set  of  PropX 
validity  rules  in  Figure  A.2. 

We  present  the  soundness  of  PropX  interpretation  (validity  rules),  as  previously  dis¬ 
cussed  in  Theorem  4.1  and  Theorem  6.1,  as  follows. 

Theorem  A.l  (Soundness  of  XCAP  PropX  Interpretation) 

1-  If  I(/>)]]>ivi,thenp; 

2.  if  Jcptr(f ,  a)  then  T^f )  =  a; 

3.  if  [[ref(l, -t) 0  then  <E>(1)  =  t; 

4.  if  [[PAQ]]^  then  [Pjq,^  and  [[Qflq,^; 

5.  if  [[PVQ]]^  then  either  [[P]]^  or 

6.  if  [P^Q]]r<J)  and  [[P]].^  then  IQ]]^; 

7.  if  [[VxiA.P]]^  and  B:A  then  [[P[S/x]]]^$; 

8.  if  [[3x:A.P]](I/(I)  then  there  exists  B:A  such  that  [[P[S/x] ]]q, 
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(. PropX )  P,Q 


(P) 

cptr(f ,  a) 
ref(l,t) 

PAQ 
PVQ 
P-*Q 
¥.x:A.P 
3x:A.  P 

¥a:A— ^PropX.P 
3a  :A— >PropX.P 


lifted  meta  proposition 
embedded  code  pointer 
referencecell  pointer 
con  junction 
disjunction 
implication 
universal  quantification 
existential  quantification 
impredicative  universal  quantification 
impredicative  existential  quantification 


(ji  a:  A^  PropX. he:  A. P  B ) 


recursive  specification 


( CdHpSpec ) 

¥ 

::=  {f->a}* 

(DiH  pSpec) 

(. Assertion ) 

a 

G  State  — >  PropX 

( WordTy ) 

t 

G  Word  — ►  PropX 

( Env ) 

r 

::=  ■  |  F,P 

Figure  A.l:  Assertion  language  of  the  full-featured  XCAP 
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r  hv[/  4,  P  (Validity  of  Extended  Propositions) 


(The following  presentation  omits  the  'F  arid  in  judgment  T  b«p,<j>  P.) 


per 


(env) 


rbp 

'P(f)  =  a 
rhcptr(f,a) 


((H) 


(CP-I) 


r>(p> 

rhcptr(f  ,a) 


ri-(p)  p  d  (rbq) 

rbq 

mf)  =  a)D(rhQ) 


rbq 


rPref(l,t) 

(RF-I) 

v  5  / 

ri-iq 

rbp  rhq  ,  „ 

n-PAq 

( A-El) 

rbPAq 

rhPAq 

rhp 

rbq 

r  hp  cv  Ti\ 

rbq 

(V-I2) 

ri-pvq 

r,pbR 

rbpvq [ w  j 

rbpvq 

rbR 

((HO 

(CP-E) 

-  (rf-e) 

(A-E2) 

r,qhR 


r,phQ 


(— I) 


B:A 


rbp^q 

rhP[S/jc]  VB:A 
TEYx-.A.P 

T3P[B/x] 


rbp-»q  rhp 
rbq 

r  I- Vje:A.  p 


(^-E) 


B:A 


(ill) 


FE3x:A.P 


ThP  [B/x\ 

r,P[S/jc]  bq 


MB-.A 


rh3i:A.P 
FhP[a/a]  Va:A— >PropX 


rhq 

a  :A-+PropX 


rhP[a/a] 


r\~Va:A^PropX.  P  T\- 3a:  A  ^PropX.  P 

B:A  T\-P[B/x\[pa:A—>  PropX.Xx-.A.P /a\ 


(iEl) 


(3-12) 


n-  (/m  a:A->PropX.hc:A.P  B ) 


Oi-I) 


Figure  A.2:  Validity  rules  for  extended  propositions  of  the  full-featured  XCAP 
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9.  if  [[Va:A  — >PropX.  P]]^^  and  a :A-^PropX  then  [[P[a/a]  J»j/  <j>; 

10.  if  J3a:A— >PropX.  P]]^,^  then  there  exists  a:A  -^PropX  such  that  [fP[a/'a]  ]],.F  (t>; 

11.  if  [(/f  a.tauA.P  B)  then  [[P[B/x][(p  a.Xx:A.P  )/a]]]^^. 


Corollary  A.2  (XCAP  Consistency)  [[  (False)  J]^  ^  is  not  provable. 

For  the  proof,  we  follow  the  syntactic  normalization  proof  methods  in  Pfenning  [51]. 
The  validity  of  extended  propositions  rules  of  form  F  F>j< <j>  P  in  Figure  A.2  are  natural 
deduction  rules.  We  classify  them  into  the  following  two  kinds  (and  call  them  altogether 
as  normal  natural  validity  rules)  as  shown  in  Figure  A.3. 

r  bvj<  $  P  -ff-  Extended  Proposition  P  has  a  normal  deduction,  and 

r  P  |  Extended  Proposition  P  is  extracted  from  a  hypodissertation. 


We  define  the  annotated  natural  deduction  rules  by  annotating  each  normal  validity  rules 
with  a  "+"  symbol  as  F  K[<  4,  P  ft  and  F  KF  cj)  P  |  and  adding  the  following  coercion  rule. 


r  Fm  4)  P  1*1 


rh+$p| 


(COER') 


We  then  define  the  sequent  style  validity  rules  of  form  I  =>ij/  <j>  p  in  Figure  A.4  and 
extend  the  sequent  rules  by  annotating  sequent  judgments  with  a  "+"  as  T  (t>  P  and 
adding  the  cut  rule. 


r 


+ 

'n.o 


Q 


(CUT) 


The  normalization  proof  process  is: 


rff,$p  Ad  rh+j4)Pi>  a. 9  r  ^  p  a.i i  t=^>p:<2>p  a 6  r i— ^  p  -fi . 

First,  natural  deduction  derivations  are  mapped  to  derivations  in  sequent  validity 
rules  with  cut.  Then  we  do  cut-elimination  in  sequent  rules,  and  map  the  new  cut-free 
sequent  derivation  back  to  a  normal  natural  deduction  derivation.  Soundness  of  PropX 
interpretation  can  then  be  proved,  since  the  last  rule  in  a  normal  natural  deduction  deriva¬ 
tion  must  be  one  of  the  introduction  rules.  We  prove  the  following  theorems  to  construct 
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r  p  ff  r  b\^<j,  p  i 


(Validity  of  Extended  Propositions) 


(The following  rules  omits  the  'F  and  in  judgments  T  P-ft-  and  T  b^#  P  j.) 


rhPi 

rnpfr 


(COER) 


pgr 
rhp  | 


(env) 


Fh(p)jt 


m 


Fh(P)i  p  d  (ri-Qi» 


(0-E) 


^(f)  =  a 
r  hcptr(f ,  a)  -ft- 

Mz! 

r  b  ref  (1,  tOft 

n-pf  ri-qn 


(CP-I) 

(RF-I) 


rhqn 

rhcptr(f,a)|  (^(f)  =  a)  D  (rhqn) 
rhqfr 

r href(i,t) i  (4>(i)=t)  d  (rhqn) 


rhqn 


(CP-E) 

(rf-e) 


rhPAqfr 


( A-El) 


rhpn 

rbpvqfr 


rbqn 


rbpvqfr 

r,pbqn 


(¥-12) 


rbPAq | 
rbp  | 

rbpvq| 


rbPAq | 
rbq| 

r,pbRn 


( A-E2) 

r,qbRf 


(— I) 


rbp-»q  j 


rbRfr 
rbpn 


B:A 


rbp^qn 

rbP[S/^n  V  B:A 
r  bW;t:A.P  n 

rbp[B/x]n 


(¥-ll) 


rbq  | 

rbWx:A.P| 


(— »"E) 
B:A 


(ill) 


rb3x:A.P  j 


EEP[B/x]  | 

r,p[s/x]  bqn 


Vfi:A 


Tb3x:A.P  f) 

FhP[a/a]  n  V  aiA — >PropX 


rbqn 

a:A— >PropX 


(3-El) 


rbP[a/a]  n 


rb¥a:A^PropX.P  j(  T  \~3a:A^PropX.P  f 

B:A  Tb  P[B/x][fia:A  PropX  .far.A.P /a]  ff 


(3-12) 


Tb  (pa:A^PropX.foc:A.P  B) 


CM 


Figure  A.3:  Normal  natural  deduction  validity  rules 
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r  P  ( Validity  of  Extended  Propositions) 


(The  following  rules  omits  the  'F  and  <£>  in  judgment  Y  =^<j>  P. ) 


per 


(init) 


p 

^(f)  =  a 
T  ==>  cptr(f  ,a) 

Mzl 

r  ==>  ref(l.  t 

r^-p  r^-Q 


(p) 


«H) 


p  p>  (r,(p)  =>  Q) 

r,  (p)  = =>  q 


((H) 


(CP-R)  (^)  =  ^  (rcp,r(f.a)^Q)  (cp_L) 


(rf-r) 


T,cptr(f,a)  =>  Q 

(^>(l)  =  t)  3  (r,ref(l,t)=^q) 
T,  ref(l,t)  ==>  Q 


(RF-L) 


( A-R) 


r,PAQ,P  ^  R  r,PAQ,Q^R  t 

r  n^n  ( A-Ll)  ^  —  ( A-L2) 


(¥-Rl) 


t,p^q 


(  *~r) 


p^q 

Y^?[B/x]  VB:A 

r^yX:A.p 

B:A  Y  =>■  V[B/x\ 


(¥-Rl) 


(3-r1) 


3x:A.P 

Y  =¥  P[a/a]  V  a \A^PropX 


R  v " "  '  r,  PAQ  ==>  R 

.  r.P¥Q,P^-R  r,P¥Q,Q  =>  R 

V  '  T,P¥Q^R 

r,p-»q^>p  r,p-»q,p^-R  . 

- r,p^Q=.R  - (^'L) 

r,¥x:A.P,P[5/.*:]  ==>  Q  B:A 
r,¥v:A.P  =^>  Q 

Y,3x\A.?,'P[B/x}  =>-  Q  MB'. A 
r,  3x:A.  P  =>  Q 

a -.A^PropX  Y  =>  P[a/a 


(¥-L) 


(¥-r2) 


? a:A-*PropX.P  T  =>  3a :A— >PropX.P 

B:A  Y  P[B/x]\fia:A  ^  PropX.hr.A. P/a] 


(3-Ll) 
(3-r2) 


T  ==>  (p  a:A-*PropX.hc:A.P  B) 


(P- R) 


Figure  A.4:  Sequent  style  validity  rules 
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the  proof.  We  use  structural  induction  in  most  of  the  proof.  The  full  proof  has  been  mech¬ 
anized  in  the  Coq  proof  assistant. 

Theorem  A.3  (Soundness  of  Normal  Deductions) 

1.  If  r  hip.<p  P  fi  then  r  hip  <j>  P,  and 

2.  if  r  hipj(p  P  |  then  T  hip,<p  P. 

Theorem  A.4  (Soundness  of  Annotated  Deductions) 

1.  If  r  h^  .j,  P  fi  then  r  hip  <j>  P,  and 

2.  if  r  h^  P  I  then  T  hip,<p  P. 

Theorem  A.5  (Completeness  of  Annotated  Deductions) 

1.  If  r  hip  <j)  P  then  T  h+  0  P  and 

2.  if  T  hipj(j,  P  then  F  h^,  ^  P  |. 

Theorem  A.6  (Soundness  of  Sequent  Calculus) 

If  r  =^ip<p  P  then  r  hip  cp  P  "O'. 

Theorem  A.7  (Completeness  of  Sequent  Derivations) 

1.  If  r  hip.cp  P  fi  then  r  =^ip,ii>  P,  and 

2.  if  r  hip  $  P  l  and  T,  P  =><p,<p  Q  then  T  =^ip<p  Q. 

Theorem  A.8  (Soundness  of  Sequent  Calculus  with  Cut) 

If  T  ,p  P  then  T  h^0  P  t 

Theorem  A.9  (Completeness  of  Sequent  Calculus  with  Cut) 

1.  If  T  h vj>  cp,  P  fl  then  T  j(p  P,  and 

2.  if  T  h^0  P  |  and  T,  P  =^3,  Q  then  T  =^^)(p  Q. 
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Theorem  A.10  (Admissibility  of  Cut) 

If  T  =>4/  $  P  and  T,P  =^4/^  Q  then  T  =^4',$  Q. 

Theorem  A.ll  (Cut  Elimination) 

If  T  ^  P  then  T  =^4',<i>  P- 

Theorem  A.12  (Normalization  for  Natural  Deduction) 

If  T I — 4',u>  P  then  T I — 4'.<i>  P  ff'. 

A  special  form  of  the  above  theorem  is  "if  H P  ]] 4»,«j>  then  •  Py,®  P  t". 
PropX  interpretation  (Theorem  A.l)  can  be  proved  using  this  theorem. 


The  soundness  of 


140 


Appendix  B 


XCAP  Soundness  Proof 


Due  to  the  usage  of  simple  semantic  subsumptions  (=>  and  =>c,  defined  using  logical  im¬ 
plication  D,  as  in  Figure  3.3  and  Figure  6.4),  it  is  straight-forward  to  prove  the  soundness 
of  XCAP  inference  rules  using  the  syntactic  soundness  approach  proposed  by  Wright  and 
Felleisen  [59].  In  this  section,  we  present  the  proof  sketch  for  the  soundness  of  XCAP,  as 
discussed  in  Chapter  3,  Chapter  4,  and  Chapter  5. 

Lemma  B.l  (XCAP  Instruction  Sequence  Weakening) 

If 'PI- {a}  I,  'Per,  and  a,=>athen'P/ h{a'}I. 

Proof  Sketch.  The  proof  is  by  induction  over  the  derivation  'P  b  {a}  I,  named  as  ©. 

Case  SEQ.  The  derivation  ©  has  the  form 

a^ca"  'Ph{a"}F 
'Ph{a}c;l' 

We  have 

1.  from  a=>  a'  and  a  =>c  a"  it  follows  that  a'  =?>c  a"; 

2.  from  'P  h  {a"}  F  by  the  induction  hypodissertation  it  follows  that  'P/  F  {a"}  I'. 

Case  JD.  The  derivation  ©  has  the  form 

a^'P(f)  f  Gdom('P) 

rF{^}]df 
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From  a=>  a7  and  a  =>• *  lP(f )  it  follows  that  a7  =>■  'P(f ). 

Case  BGTI.  The  derivation  CD  has  the  form 

(A,(M,R).(R(r,)<i)  A  a(H,R))^a77  Th{a"}I' 

(A,(H,R).(R(r s)>i)  A  a(H,R))  ^'P(f)  fGdom('P) 

'PI- {a} bgti  rs,/,f ;F 

We  have 

1.  from  a=>a7  and  (A,(M,M).  (M(r1)  <  i)  A  a  (H,R))  =>•  a"  it  follows  that 
(A,(H,R).  (R(r,)  <  i)  A  a7  (H,R))  =>  a"; 

2.  from  lP  h  {a77} I7  and  the  induction  hypodissertation  it  follows  that  'P7  h  {a77}  I7; 

3.  from  a=>a7  and  (A,(M,M).  (M(r1)  >i)  A  a  (H,R))  =>•  'P(f)  it  follows  that 
(X(H,M).(M(ri.)>/)  A  a!  (H,R))  =>-  'P(f). 

Case  jmp.  The  derivation  CD  has  the  form 

a  =>  (X(H,R). a77  (H,R)  A  cptr(R(r), a77)) 

*P  h{a}jmp  r 

From  a=>a7  and  a  =>•  (X(BI,R). a77  (H,R)  A  cptr(R(r),a77))  it  follows  that 

a7  =►  (X(H,R).a77  (H,R)  A  cptr(R(r),a77)). 

Case  ECP.  The  derivation  CD  has  the  form 

(AS.cptr(f,'P(f))AaS)=>a77  f  Gdom('P)  'Ph{a"}I 

'Ph{a}I 

We  have 

1.  from  a=^a7  and  (XS.cptr(f,'P(f))AaS)  =$■  a"  it  follows  that 
(A,S.cptr(f  ^(f ))  Aa7  S)  =>■  a77; 

2.  from  VP  I-  {a77} I  by  the  induction  hypodissertation  it  follows  that  'P7  h  {a77}  I.  ■ 

Lemma  B.2  (XCAP  Code  Heap  Typing) 

If  hCiT and  f  Gdom('P)  then  f  Gdom(C)  and h{'P(f)}C(f). 

Proof  Sketch.  The  proof  is  by  induction  over  the  derivation  F  C :  VP. 

Case  CDHP.  The  derivation  has  the  form 
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qyh{a,}II;  Vf, 

From  f  edom('F)  it  follows  that  f  Gdom(C)  and  'F^  F{xF(f)}C(f). 

Case  link.  The  derivation  has  the  form 

TVi  F  Ci IT',  ^in2  hC2:T2  *Fm(f)  =*Fw2(f) 

dom(Ci)ndom(C2)  =  0  Vf  Edorn(vFm)ndom('F;jv2) 
,PwlU'Fw2l-CiUC2:'F1U'F2 

From  dom(Ci)ndom(C2)  =0  it  follows  that  dom(T/i)ndom(*f/2)  =0.  Then  from  f  Edom('F) 
it  follows  that  f  E  domfTp),  where  i  could  be  either  1  or  2.  From  VF/V/  F  Q :  lF,  by  the 
induction  hypodissertation  it  follows  that  f  Edom(C,-)  and  lF;v/  F  {vF;(f) }  C,-(f ). 

From  f  Edom(Q)  it  follows  that  f  Edom(CiUC2). 

From  x¥INi  F{'F,-(f)}Ci-(f)  and  Instruction  Sequence  Weakening  (Lemma  B.l)  it 
follows  that  ^  i u  ^w2  F  {^1  U^2 (f ) }  Cl  U  C2(f ) .  ■ 

Lemma  B.3  (XCAP  State  Typing) 

If  F  C:*F  and  [[cptr(f , a)  then  f  Edom(C)  and  F{a}C(f ). 

Proof  Sketch.  From  [cptr(f ,  a)  by  PropX  Validity  Soundness  (Lemma  A.l)  it  follows  that 
f  Edom(*F)  and  xF(f)  =  a.  By  Code  Heap  Typing  (Lemma  B.2)  it  follows  that  f  Edom(C) 
and  'F/JV  F{a}C(f).  ■ 

Lemma  B.4  (XCAP  Progress) 

If  T1,.  F {a}  IP,  then  there  exists  a  program  P7  such  that  P  i — >  P7. 

Proof  Sketch.  Derivation  'Fg  F  {a}P  has  the  following  form. 

'Fg  F  C : 'Fg  ([[a]]¥cS)  ^Pja}! 

'FcF{a}(C,S,I) 

The  proof  is  by  induction  over  derivation  *¥G  F  {a}  I. 

Case  SEQ,  JD,  BGTI  and  JMP.  the  proof  is  by  simple  inspections. 

Case  ECP.  The  proof  is  by  the  induction  hypodissertation.  ■ 

Lemma  B.5  (XCAP  Preservation) 

If  'Fg  F  {a}  P  and  P  i — *  P7  then  there  exists  an  assertion  a7  such  that  VF(;  F  {a7} P7. 
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Proof  Sketch.  Suppose  P=  (C,  We  name  derivation^  b{a}Pas  D,  which  has 

the  following  form. 

'P.bC:^  ([[a]]m  (H,M))  ^hja}! 

( j 

'PGb{a}(C,(H,R),I) 

The  proof  is  by  induction  over  the  derivation  \PG  b  {a}  I,  named  as  £. 

Case  SEQ.  The  derivation  £  has  the  form 

a  =^c  a!  'PGb{a,}F 

By  the  operational  semantics,  P'  =  (C,Nextc(HI,M),F).  Then 

1.  FGbC:FG  is  in  ©; 

2.  from  ( [[ a ]] ^  (H,M))  and  a  a'  it  follows  that  ([[a']]^  Nextc(H,M)); 

G  G 

3.  »PC  b{a'}F  is  in  £. 

Case  JD.  The  derivation  £  has  the  form 

a=>'PG(f)  fedomOPc) 

I- (al jd  f 

By  the  operational  semantics,  P'  =  (C,  (H,M),C(f )).  Then 

1.  FGbC:FG  is  in  ©; 

2.  from  ([[a]] ^  (H,M))  and  a  'Pg(f)  it  follows  that  ([[*PG(f)  ]]^ 

G  G 

3.  by  VPG  b  Ci'Pg,  f  Gdom^g),  and  Code  Heap  Typing  (Lemma  B.2)  it  follows  that 
'PGb{'PG(f)}c(f). 


Case  BGTI.  The  derivation  £  has  the  form 

(A,(H,R).(R(r,)<i)  A  a  (H,M))  =>  a'  »PG  b{a'}F 

(X(M,R).(R(rJ)>i)  A  a(H,R))=^'PG(f)  fedomOPc) 
'Pc  b{a} bgti  rs,(,f;F 

By  the  operational  semantics,  when  M(r,)  > i,  P'  =  (C,(H,M),C(f )).  Then 
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1.  ^¥g  \-C:'¥e  is  in  ©; 


2.  from  ([[  a]]^,  (H,M))  and  (X(H,M).  (M(ri)  <  i)  A  a  (H,M))  =t-  a'  it  follows  that 

G 

G 

3.  by  'Pg  b  Ci'hg,  f  edom^,.),  and  Code  Heap  Typing  (Lemma  B.2)  it  follows  that 

H{^G(f)}C(f). 

By  the  operational  semantics,  when  F^r*)  <  i,  P'  =  (C,  (H,  M) ,  F) .  Then 

1.  WG  hC:Pc  is  in  ©; 

2.  from  ( [[  a ]] ^  (H,M))  and  (X(H,M).  (M(ri)  <i)  A  a  (H,M))  =>-  a'  it  follows  that 

G 

& 

3.  x¥a  h{a'}F  is  in  £. 

Case  jmp.  The  derivation  £  has  the  form 

a=>-  (^(Hljl^.a'  (H,M)  A  cptr(M(r), a')) 
xf'Gl-{a}jmpr 

From  ( [[ a ]] vj,  (H,M))  and  a  =>  (X(HI,M).  a7  (H,M)  A  cptr(M(r),a'))  it  follows  that 

G 

[[a'Jxp  (H,M)  and  [cptr(M(r),a/)]]Vj,  . 

G  G 

By  the  operational  semantics,  P'  =  (C,  (H,M),C(M(r))).  Then 

1.  PGhC:Fc  is  in©; 

2.  ( H ar ]] jj,  (H,M))  is  from  above; 

G 

3.  by  F  C :  *¥c,  [[cptr(M(r),a/)]]VI,  ,  and  State  Typing  (Lemma  B.3)  it  follows  that 

G 

^Ha'ICftW). 

Case  ECP.  The  derivation  £  has  the  form 

(XS.cptr(f  )  Aa  S)  =>  a'  fGdom^g)  'f/Gh{a/}I 

^{a}! 
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From  ( [[  a ]] xj,  (XS.cptr(f  ,*F0(f ))  A  a  §)  =>  a!,  and  f  edom(*PG)  it  follows  that 

G 

(|[a']L  Together  with  lPG  h  {a7}  I,  the  prove  is  completed  by  using  the  induction 

G 

hypodissertation.  ■ 

Theorem  B.6  (XCAP  Soundness) 

If  'Pg  h  {a} P,  then  for  all  natural  number  n,  there  exists  a  program  P'  such  that  Pi — >"  P'. 
Proof  Sketch.  By  simple  induction  on  n  and  using  Progress  (Lemma  B.4)  and  Perservation 
(Lemma  B.5).  ■ 
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Appendix  C 


TAL  to  XCAP  Translation  Typing 
Preservation  Proof 


In  this  section,  we  present  the  proof  for  the  typing  preservation  theorem  of  the  translation 
from  TAL  to  XCAP  in  Chapter  5.  Here  TAL  is  as  defined  in  Section  5.2,  not  the  "semantic" 
one  in  Section  5.3. 


Lemma  C.l  (Value  Typing  Preservation) 

If  vF;<t>  Kal  w:t  then  [rTn  w]nj,nr^-i. 

Proof  Sketch.  By  induction  on  derivation  'P;4>  hTAL  w:  t. 
Case  INT.  The  derivation  has  the  form 


xP;<hhTALw:int 


We  have  rintn  =  Xw.True,  Trivial. 

Case  CODE.  The  derivation  has  the  form 

f  Gdom(*P) 

MhXALf:code  'P(f) 

We  have  rcode  T*(f  )n  =  Xw.codeptr(w,rvP(f  )n)  =  Xw.codeptr(w,rT/_l(f )),  Trivial. 

Case  POLY.  The  derivation  has  the  form 

Tt'  'P;d>  hTAL  f  :code  [a,A]-h 
T1;  <P  I  TAl  f :  code  [A] .  r[x'/ct] 
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We  have  rcode  [Aj.rpd/oc]”1  =  Xw.codeptr(w,r[A].r[x//a]~l)  =  Aw.codeptr(w,3A.rr[x7a]n)- 

By  the  induction  hypodissertation  it  follows  that  [[rcode  [a,  A] .  T  w]]r^n  r^-i,  and  then 
Jcodeptr(w,  3  a,  A.  T-1)  ]]r>j,n  r^n. 

It  is  easy  to  show  [V§.3A.rr[T'/a]n  §  — »  3a.A.rrn  §]]rvjnr<£-i.  IT  then  follows  that 

[[codeptr(w,3A.rr[T7a]"l)]]rvI/-ir4,-,. 

Case  tuple.  The  derivation  has  the  form 

<E>(l+/-l)=X;  V/ 
xf/;<f>l-TAL 

We  have  r(xj, . . .  ,x„)n  =  Aw.  record(w,rTin, . .  .  ,rh7) 

=  Aw. ref(w,rTin)  A  ...  Aref(w+zz—  l,rT7)- 
=  Aw.  ref(w,  r<f>(w)n)  A  . . .  Aref(w+/i— 1,  r<J>(wH-w—  l)n). 

=  Aw.  ref(w, r<f>n(w))  A  . . .  Aref(w+/i— l,r<Pn(w+?z— 1)). 

Trivial. 

Case  ext.  The  derivation  has  the  form 

•hr7  T^I-tal  w:x[x7a] 

'F;<4>hTALw:3a.x 

We  have  r3a.  x  =  Aw.  3  a.  rx  w.  By  the  induction  hypodissertation  it  follows  that 

[[rx[x'/a]n  w|rqnr$i.  It  then  follows  that  J3a.rxn  w]]r»I,-i)r<I>-i. 

Case  all.  The  derivation  has  the  form 

^<£1— TAL  w:x[/ra.x/g] 
xf/;<f>HTAL  w:/ra.x 

We  have  r/ua.  xn  =  Aw.  (/i  a.  he.  (rxn  x)  w).  By  the  induction  hypodissertation  it  follows 
that  [[rx[ua.x/a]~l  w]]r>j/-i  r^-i.  It  then  follows  that  J(/i  a. he.  (rxn  x)  w)]]rvj<-i  r<j,n.  ■ 

Lemma  C.2  (Register  File  Typing  Preservation) 

If  T1; <f>  hTAL  R : T  then  [[r[].W  (H,M)]]ripn  r<J)n. 

Proof  Sketch.  Derivation  T/;<f>  hTAL  R :  T  has  the  form 

T'^KalR^X;  V/ 

T/;<f>  hTAL  R :  {ri ^Xi , . . . , r„^x;!} 
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We  have  r [] .rn  =  X(H,R).  (rTin  R(ri))  A  . . .  A  (rT„n  R(r„)). 

From  'F;  <1>  bTAL  R(r,-) :  T,  by  Value  Typing  Preservation  (Lemma  C.l)  it  follows  that 

[[  rX(,_l  M(r,')  jjrxjorcjri.  H 

Lemma  C.3  (Data  Heap  Typing  Preservation) 

If  *F  hTAL  H :  <F  then  T)!H  r»Fn  r<l>n  H. 

Proof  Sketch.  Derivation  'F  FTAL  H:<f>  has  the  form 

xF;<f>hTALH(l):T>(l)  V  lGdom (<f>)  =  dom(EI) 

We  have  rvFn  r<I>n  HI  =  Vledom(<F)  =  dom(H).[[<f>(l)  11(1)]],^^. 

From  XF;<E>  FTAL  H(l)  :<f>(l)  by  Value  Typing  Preservation  (Lemma  C.l)  it  follows  that 

r*(l)nM(i)]| 

Lemma  C.4  (State  Typing  Preservation) 

If  »F  hTAL  S :  [A] .  r  then  [[ r  [A] .  ]]  ^  S. 

Proof  Sketch.  Derivation  'F  FTAL  S :  [A] .  T  has  the  form 

•  h  Ji_  Vi  *F hTAL El : <1>  TLfo  hTAL RTjri, ... ,T„/ai, ... ,a„] 

'FFtal  (M,K):[cxi,...,a„].r 

From  'F  I  TAL  H :  T>  by  Data  Heap  Typing  Preservation  (Lemma  C.3)  it  follows  that 
ZXX  rvFn  rcf>^  H. 

From  Tb  <f>  hTAL  R :  T[ti  , . . . , T„/(Xi , . . . ,  a„]  by  Register  File  Typing  Preservation 
(Lemma  C.2)  it  follows  that  [[rr[ti, . . .  ,T„/0Ci,. . .  ,oc„]n  ({},R)]]r»j<n  r$-i.  It  then  follows  that 
[r[al )  ■  ■  ■ )  a;i]  -r”1  ({},M) 

Finally,  it  follows  that  [[ r  [ai , . . . ,  a„]  .rn  ]]  r«j<n  (H,  R) .  ■ 

Lemma  C.5  (Subtyping  Preservation) 

If  bTAL  [A].r  <  [A'].r  then  r[A].rn  =>  r[A'].rn. 

Proof  Sketch.  By  casing  derivation  I  TAL  [A] .  F  <  [A'].T'. 

Case  SUBT.  The  derivation  has  the  form 
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ADA'  VrGdom(r')  r(r)=r'(r)  A'hT(r) 
hTAL[A].r<[A'].n 

We  have  r[A] =  AS.  3  A. rrn  S  and  r[A'] Tn  =  AS.  3  A'.  rrn  S.  Trivial. 

Case  TAPP.  The  derivation  has  the  form 

r(r)=code  [a,A'].r/  A  hr' 

Kal  [A].r  <  [A].r{r  :code  [A'].n[x'/a]} 

Suppose  T  =  r^U {recode  [a,A'].r'}. 

We  have  r[A].Tn  =  AS.  3A.rTn  §  =  AS.  3  A.  rr,/n  S  Acodeptr(S.M(r),3°C  A'.r')  and 

rcode  [A'] . r [x'/a] n  =  AS.  3 A. rn  S  =  AS. 3 A. rVn  S A codeptr(S.R(r ) ,3A'T' [x'/a] ) . 

It  is  easy  to  show  [VS.3A'.T'[T7a]"lS  — *  3a,A'.rrn  SJnjn  r<j>-i.  Trivial. 

Case  PACK.  The  derivation  has  the  form 

r(r)=x[x'/a]  Al-x' 
h tal  [A] .  r  <  [A]  .r {r :  3a.  x} 

Suppose  r  =  r"  U  {r  x[x'/a]}. 

We  have  r[A].n  =  AS.  3A.rr'n  S  Arx[x'/a]n  S.R(r)  and 
r [A]  ,r{r :  3a.  x}n  =  AS.  3  A.  rr'n  S  A  3  a.  rxn  S.R(r ) .  Trivial. 

Case  UNPACK.  The  derivation  has  the  form 

r(r)  =  3a.x 

Kal  [A].r<  [a,A]T{r :x} 

Suppose  r  =  r"  U  {r  3a.  x}. 

We  have  r  [A]  =  AS.  3  A.  rr'n  S  A  3  a.  rxn  S.R(r )  and 

r[a,  A].r{r  :x}n  =  AS.  3a,A.rr/n  SArx[x'/a]n  S.R(r).  Trivial. 

Case  FOLD.  The  derivation  has  the  form 

r(r)  =  x[t/a.x/a] 
h tal  [A].r<  [A].r{r  :/ra.x} 

Suppose  r  =  r"  U  {r  x^a.x/a]}. 

We  have  r[A].rn  =  AS.  3A.rr'n  S  Arx[ua.x/a]~l  S.R(r)  and 
r [A] ,r{r : A/a. x}n  =  AS. 3  A. rVn  S  A  (/i  a.hc. rxn  x  S.R(r)).  Trivial. 

Case  UNFOLD.  The  derivation  has  the  form 
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T(r)  =/va.x 

Kal  [A].r<  [A]F{r  :x[qa.x/a]} 

Suppose  r  =  r"  U  {r  fj a.  x}. 

We  have  r[A]Fn  =  X§.  3A.rFn  S  A  (ft  a .  Xr.  rxn  x  S.M(r))  and 

rr{r:x[iua.T/a]}n  =  XS.3A.rr,nSArxLua.T/a]nS.M(r).  Trivial.  ■ 

Lemma  C.6  (Instruction  Typing  Preservation) 

If  t  bTAL  {r}c{r'}  then  r[A].r>  =*  r[A].rn. 

Proof  Sketch.  By  casing  on  derivation  VP  hTAL  { F}  c  { F' } .  Trivial.  ■ 

Lemma  C.7  (Instruction  Sequence  Typing  Preservation) 

If  W  bTAL  { [A] .  T}I  then  ^  hXCAP  {r[A],  r>} L 

Proof  Sketch.  By  induction  over  derivation  VP  hTAL  { [A] . F }H. 

case  weaken.  The  derivation  has  the  form 

1“  TAL  [A]-r<[A'].F 

^  1“  TAL  ; 

ThIAL{[A]T}I 

By  induction  hypodissertation  it  follows  that  rvFn  PXcap  {r[A'].Fn}I.  By  Subtyping 
Preservation  (Lemma  C.5)  it  follows  that  r [A] .  F1  =>  r[A'] .  FA  The  by  XCAP  Instruction 
Sequence  Weakening  (Lemma  B.l)  it  follows  that  riFn  bXCAP  {r[A].r_l}L 

case  SEQ.  The  derivation  has  the  form 

'P  hTAL  {r}c{F}  'P  hTAL  {[A].F}I  ce{add,addi,mov,movi,ld,st} 

_ 

By  induction  hypodissertation  it  follows  that  r*F~l  bXCAP  {r  [A] .  Fn}L  By  Instruction 
Typing  Preservation  (Lemma  C.6)  it  follows  that  r[A].rnli,  =^c  r[A] . F  By  XCAP  rule 
SEQ  it  follows  that  rvF~l  bXCAP  {r[A].F1}c;II. 

case  JD.  The  derivation  has  the  form 

f  edom('P)  hTA,[A].r<T(f) 

ThTAL  {[A].r}jd  f 

By  Subtyping  Preservation  (Lemma  C.5)  it  follows  that  r [A] .  F-1  =>  riF(f  )n,  and  then 
r[A].r,=*nF"l(f).  By  XCAP  rule  JD  it  follows  that  rvF“l  hXCAP  {r[A].F'}jd  f . 
case  jmp.  The  derivation  has  the  form 
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r(r)  =  code  [A'] .  V  hTAL  [A] .  r  <  [A'] .  V 

T'LTAI.{[A].r}jmpr 

By  translation  it  follows  that  r[A].rn  =>  X(H,M).cptr(M(r),r[A/].r,n).  By  Subtyping 

Preservation  (Lemma  C.5)  it  follows  that  r [A] . Tn  =>  r[A/].rn.  By  XCAP  rule  JMP  it 

follows  that  rvPn  Lxcap  {r[A].rn}jmp  r. 

case  MOVF.  The  derivation  has  the  form 

f  Gdom('P)  T'h1*L{[A].r{rrf~>code  T'(f)}}! 

^  1“  TAL  {[A].r}movi  rd)f\l 

By  induction  hypodissertation  it  follows  that  rT/_l  Lxcap  {r[A].F{r,/"->code  vP(f  )}n}I.  By 
XCAP  rule  ECP  and  SEQ  it  follows  that  rT/_l  LXcap  {r[A].rn}movi  r^,f;L  ■ 

Lemma  C.8  (Code  Heap  Typing  Preservation) 

If  TV  hTAL  C :  TJ  then  rTVn  LXCap  C :  rT'T 

Proof  Sketch.  By  induction  on  derivation  TV  hTAL  C :  TL 

case  CDHP.  The  derivation  has  the  form 

TV  Km.  W  )}C(f )  Vf  Gdom(T') 

From  TV  bTAL  {'Pff  )}C(f  )  by  Instruction  Sequence  Typing  Preservation  (Lemma  C.7)  it 
follows  that  rTV  hxcAP  {rxPn(f)}C(f). 
case  link.  The  derivation  has  the  form 

TV,  Kal  Q  iTh  TV2  hTAL  C2  ='Pw2(f ) 

dom(Ci)ndom(C2)  =0  Vf  Gdom(TV1)ndom(TV2) 

TV1UTV2KalC1UC2:T'1UT'2 

From  x¥mj  hTAL  C, :  lF,  by  Instruction  Sequence  Typing  Preservation  (Lemma  C.7)  it 
follows  that  rTV(.n  Lxcap  Q :  rTV-  By  XCAP  rule  LINK  it  follows  that 

rTVjUTV2n  Lxcap  Ci  UCzAThUTV-  ■ 

Theorem  C.9  (Program  Typing  Preservation) 

If  T>  L TAL { [A] . T} P  then  ^  LXCAP {' “[A] . rn}P. 

Proof  Sketch.  Derivation  T*  Ltal  {[A] .  I"}  IP  has  the  form 
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>yGhTAL§:[A].r  ^GhTAL{[A].r}i 
'pGhTAL{[A].r}(c,s,i) 


^GhTALC:^G 


From  'Fg  hTAL  C :  VPG  by  Code  Heap  Typing  Preservation  (Lemma  C.8)  it  follows  that 

^ XCAP  C  •  r'f,G_l‘ 

From  VF0  hTAL  §  :  [A] .  F  by  State  Typing  Preservation  (Lemma  C.4)  it  follows  that 

HA].ni™ -,s. 

U 

From  VF0  FXAL  {[A] .  F}H  by  Instruction  Sequence  Typing  Preservation  (Lemma  C.7)  it 
follows  that  \PG  F xcap  { [A] .  L)Ii.  ■ 
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Appendix  D 


XCAP86  Soundness  Proof 


Following  the  soundness  proof  of  the  XCAP  in  Appendix  B,  we  present  the  soundness 
proof  of  XCAP86  discussed  in  Chapter  6. 

Lemma  D.l  (XCAP86  Instruction  Sequence  Weakening) 

If 'PI- {a}  I,  'Per,  and  a'  =>  a  then  T*7  h  {a7} L 

Proof  Sketch.  The  proof  is  by  induction  over  the  derivation  'F  h  {a}  I,  named  as  CD. 

Case  SEQ.  The  derivation  *D  has  the  form 

a  =>c  a77  fh{a"}I' 
fh{a}c;I' 

We  have 

1.  from  a=>  a7  and  a  =tc  a"  it  follows  that  a7  =>c  a77; 

2.  from  r  h  {a77}  I7  by  the  induction  hypodissertation  it  follows  that  VF7  F  {a77}  I7. 

Case  jmpi.  The  derivation  CD  has  the  form 

a  =>-  'F(f)  fedompF) 
r  h{a}jmp  f 

From  a=^a7  and  a  =>•  'P(f )  it  follows  that  a7  =>■  'F(f). 

Case  JCC.  The  derivation  CD  has  the  form 
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(X(H,R,F).(-.F(cc))  A  a  (H,M,F))  =>  a77  'Fb{a77}F 

(X(H,R,F).  (F(cc))  A  a  (H,R,F))  =>  »F(f )  f  €  dom(^) 

'Fhlajjccf;!' 

We  have 

1.  from  a=>a7  and  (A,(M,M,F).  (-iF(cc))  A  a  (H,M,F))  =>■  a"  it  follows  that 
(X(H,R,F).(-.F(cc))  A  a'  (H,R,F))  =>  a"; 

2.  from  'h  h  {a"} F  and  the  induction  hypodissertation  it  follows  that  'F7  h  {a"}  I'; 

3.  from  a=>a7  and  (A,(M,R,F).  (F(cc))  A  a  (H,M,F))  => 'F(f)  it  follows  that 
(A,(El,R,F).(F(cc)>  A  a'  (H,R,F))  =>■  'F(f). 

Case  jmpr.  The  derivation  CD  has  the  form 

a  =>-  X(BI,R,F).  cptr(R(r),  a77)  a  =>-  a77 

*F  h{a}jmp  r 

From  a=^a7,  a  =>-  X(H,M,F).  cptr(M(r),  a7),  and  a  =>•  a77  it  follows  that 

a7  =>■  X(H,  R,  F) .  cptr(M(r) ,  a7),  and  a7  =>■  a77. 

Case  ECP.  The  derivation  CD  has  the  form 

(XS.cptr(f,'F(f))AaS)  =>  a77  fGdom('P)  Fh{a77}I 

'Fb{a}I 

We  have 

1.  from  a=^a7  and  (XS.cptr(f,\F(f))Aa§)  =$■  a"  it  follows  that 
(A,S.cptr(f  ^(f ))  Aa7  §)  =>■  a77; 

2.  from *  lF  h  {a77} I  by  the  induction  hypodissertation  it  follows  that  'F7  F  {a77}  li. 

Case  CALLI.  The  derivation  CD  has  the  form 

^pushf^f)  f  e  don-1  QT) 

'FI- {a} call  f;[f ret\ 

From  a^a7  and  a  =Apush  fm  'F(f),  it  follows  that  a7  =^push  f(w  'F(f ). 

Case  CALLR.  The  derivation  CD  has  the  form 
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a  =►  X(H,  R,  F) .  cptr(R(r) ,  a")  a  =»push  f  m  a" 

'Fh {a} call  r;[f ret\ 

From  a=>  a7,  a  =>•  X(H,M,F).cptr(M(r),  a"),  and  a  =4-push  f  .  f  a",  it  follows  that 
a7  =>  ^(H,M,F).cptr(M(r),a77),  and  a7  =4-push  fn(  a". 

Case  RET.  The  derivation  CD  has  the  form 

a  X(H,  R,  F) .  cptr(H(M(esp ) ) ,  a77)  a  =^op  a77 

'Fh{a}ret 

From  a=^a7,  a  X(H,M,F).cptr(HI(M(esp)),a77),  and  a  =^op  a",  it  follows  that 

a7  =>■  X(BI,M,F).cptr(BI(M(esp)),a77)/  and  a7  =^op  a77.  ■ 

Lemma  D.2  (XCAP86  Code  Heap  Typing) 

If  'Fw  hC:T and  f  edom('F)  then  f  edom(C)  and  'P/v  F{'F(f)}C(f ). 

Proof  Sketch.  The  proof  is  same  as  the  XCAP  Code  Heap  Typing  (Lemma  B.2).  ■ 

Lemma  D.3  (XCAP86  State  Typing) 

If  h  C:*P  and  [cptr(f , a)  then  f  Gdom(C)  and  'P,^  F{a}C(f ). 

Proof  Sketch.  The  proof  is  same  as  the  XCAP  State  Typing  (Lemma  B.3).  ■ 

Lemma  D.4  (XCAP86  Progress) 

If  'Pg  F  {a}  IP,  then  there  exists  a  program  P7  such  that  P  i — >  P7. 

Proof  Sketch.  Derivation  *¥c  F  {a}P  has  the  following  form. 

'FcFC:'FG  ((DC(C)  *  [[a]],j,  )  S)  lookup(C,pc,I)  'PGh{a}I 

G 

'Pg  F{a}  (8,  pc) 

The  proof  is  by  induction  over  derivation  'Pg  F  {a}  I. 

Case  SEQ,  jmpi,  JCC,  jmpr,  CALLI,  CATER,  and  ret.  the  proof  is  by  simple  inspections. 
Case  ECP.  The  proof  is  by  the  induction  hypodissertation.  ■ 

Lemma  D.5  (XCAP86  Preservation) 

If  'Pg  F  {a}  P  and  P  i — >  P7  then  there  exists  an  assertion  a7  such  that  'F(;  F  { a7}  P7. 

Proof  Sketch.  Suppose  P=  ((H,M,F),pc).  We  name  derivation  'Pg  F{a}Pas  CD,  which 
has  the  following  form. 
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'¥g\-C:'¥g  ((DC(C)*[[a]]vj,G)  (H,M,F))  lookup(C,pc,I)  T'gbja}! 

^ch{a}((H,M,F  ),pc) 

The  proof  is  by  induction  over  the  derivation  b  {a} I,  named  as  £. 

Case  SEQ.  The  derivation  £  has  the  form 

a  =>c  a!  'Pg  b{a7}F 
1“  {a}  c;F 

By  the  operational  semantics,  P7  =  (Nextc(EI,M,F),Hpc).  Then 

1.  T'g  bCLT'g  is  in  £>; 

2.  from  ((DC(C)  *  [[aj^  )  (H,M,F))  and  a  =^;  a7  it  follows  that 

G 

((DCtCMa']]^)  Nextc(H,M,F)); 

3.  from  lookup(C,pc,I)  and  Dc(H ,pc)  =  (c,npc)  it  follows  lookup(C,«pc,F); 

4.  T'g  b{a'}F  is  in  £. 

Case  jmpi.  The  derivation  £  has  the  form 

a^T'Jf)  f  Gdom('f/c) 

'f'c  F{a}jmp  f 

By  the  operational  semantics,  P7  =  ((H,M,F),f).  Then 

1.  T'g  h<C:,Fc  is  in  £; 

2.  from  ((DC(C)  *  [[a]^  )  (H,M,F))  and  a  xPG(f)  it  follows  that 
((DC(C)*rPG(f)fl™  )  (H,M,F)); 

G 

3.  from  f  Gdom('f/0)  and  h  Ch'Tg  by  Code  Heap  Typing  (Lemma  D.2)  it  follows 
that  f  Gdom(C),  and  it  follows  that  lookup(C,f  ,C(f )); 

4.  from  f  Gdom('f/0)  and  b  C:T/G  by  Code  Heap  Typing  (Lemma  D.2)  it  follows 
that x¥g  b{'PG(f)}C(f ). 

Case  JCC.  The  derivation  £  has  the  form 
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(X(H,R,F).(-.F(cc)>  A  a  (H,R,F))  =>  a7  'FGh{a,}I' 

(X(H,R,F).  (F(cc))  A  a  (H,R,F))  =»  ¥G(f )  f  €  dom^) 

^0h{a}jccf;F 

By  the  operational  semantics,  when  F(cc),  P7  =  ((H,M,F),f ).  Then 

1.  Vcl-C:¥c  is  in  ©; 

2.  from  ((DC(C)*[[a]](j,  )  (H,R,F))  and  (X(H,R,F).  (F(cc))  A  a  (H,R,F))  =>  T'Jf )  it 

G 

follows  that  ((DC(C)*[['f/G(f)]]>j<  )  (H,R,F)); 

G 

3.  from  f  Gdom('f/0)  and  VPG  h  C :  xilc  by  Code  Heap  Typing  (Lemma  D.2)  it  follows 
that  f  Gdom(C),  and  it  follows  that  lookup(C,f  ,C(f )); 

4.  from  f  Gdom('f/0)  and  h  C:'FG  by  Code  Heap  Typing  (Lemma  D.2)  it  follows 
that  'PG  L{'TG(f)}C(f ). 

By  the  operational  semantics,  when  -iF(cc),  P7  =  ((H.M.Fj./i/Jc).  Then 

1.  x¥g  hC:Pc  is  in  ©; 

2.  from  ((DC(C)  *  [[aj^  )  (H,M,F))  and  (X(H,M,F).  (-iF(cc))  A  a  (H,R,F))  =>- a7  it 

G 

follows  that  ((DC (C)  *  [[a']] q,  )  (H,M,F)); 

G 

3.  from  lookup(C,pc,I)  and  Dc(H ,pc)  =  (c,npc)  it  follows  lookup(C,npc,F); 

4.  'Tg  L{a,}F  is  in  £. 

Case  jmpr.  The  derivation  £  has  the  form 

a  =>•  A,(H,R,F).  cptr(R(r),  a7)  a  a7 
l“{a}jmp  r 

From  ((DC(C)  *  [[a]]vj,  )  (H,M,F)),  a  =>■  X(H,M,F).  cptr(M(r),  a7)  and  a  =>■  a7  it  follows  that 

G 

((DC(C)  *  [[a7]]^,  )  (H,M,F))  and  fcptr(M(r), a7)  . 

G  G 

By  the  operational  semantics,  P7  =  ((H,M,F),M(r)).  Then 
1.  FGhC:Fc  is  in  £>; 
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2.  ((DC(C)  *  [[ a' ]] ^  )  (H,M,F))  is  from  above; 

G 

3.  by  'Fg  F  Ci'Fg,  [[cptr(M(r),a/)]]^)  ,  and  State  Typing  (Lemma  D.3)  it  follows  that 

G 

M(r)  Gdom(C),  and  it  follows  that  lookup(C,M(r),C(M(r))); 

4.  by  'Fg  h  C :  \PG,  Jcptr(M(r) ,  a')  ]]^<  ,  and  State  Typing  (Lemma  D.3)  it  follows  that 

G 

^Ka'jKfr). 

Case  ECP.  The  derivation  £  has  the  form 

(XS.cptr(f,'f/G(f))AaS)  =>  a'  fedomOFG)  'Pch{a,}I 

From  ((DC(C)  *  [[a]]^  )  (H,M,F)),  (A,S.cptr(f  ,'Fc(f ))  Aa  §)  =$■  a',  and  f  edom(vFc)  it 

G 

follows  that  ((DC (C)  *  [[a* 1 2 3 4 * * 7]] .j,  )  (H,R,F)).  Together  with  \FC  F  {a7} I,  the  prove  is 

G 

completed  by  using  the  induction  hypodissertation. 

Case  CALLI.  The  derivation  £  has  the  form 

a^-pushfre,  *Pc(f)  f  £dom(xf/c) 

'Fg  F {a} call  f;[fref] 

By  the  operational  semantics,  P7  =  (Nextpush  f  a(HI,R,F),  f ).  Then 

1.  »FG  FC:^  is  in  £>; 

2.  from  ((DC(C)  *  [[ a]]^  )  (H,R,F))  and  a  =kpush  ±m  ^(f)  it  follows  that 
((DC(C)  *  [['Fc(f)  Nextpushfref(H,M,F)); 

3.  from  f  Gdom('f/G)  and  F  C :  x¥c  by  Code  Heap  Typing  (Lemma  D.2)  it  follows 
that  f  Gdom(C),  and  it  follows  that  lookup(C,f  ,C(f )); 

4.  from  f  Gdom('FG)  and  VTG  F  (CL'Fg  by  Code  Heap  Typing  (Lemma  D.2)  it  follows 

that  'Fg  F{'FG(f)}C(f). 

Case  CALLR.  The  derivation  £  has  the  form 

a  =>■  A,(HI,R,F).cptr(R(r),a7)  a=>pushfm  a7 
'Fg  F {a} call  r;[fm] 
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From  ((DC(C)  *  [[a]]¥  )  (HI, M, IF)),  a  =>-  X(HI,M,F).cptr(M(r),a7)  and  a  =^push  ±ra  a7  it  follows 
that  [[cptr(M(r),  a7) ]]m  and  ((DC(C)  *  [a']|™  )  Next  h  f  (H,R,F)). 

G  G  ~ 

By  the  operational  semantics,  P7  =  (Nextpush  f  ^(EI,M,F),M(r)).  Then 

1.  is  in  ®; 

2.  ((DC(C)  *  [[a7]]^)  Nextpush  fret(H,R,F))  is  from  above; 

3.  by  'Pg  h  C :  Xf/G,  Jcptr(M(r) ,  a7)  ]]^<  ,  and  State  Typing  (Lemma  D.3)  it  follows  that 

G 

M(r)  edom(C),  and  it  follows  that  lookup(C,M(r),C(M(r))); 

4.  by  'Fg  h  Cb'Fg,  Jcptr(M(r),  a7)  ]]^<  ,  and  State  Typing  (Lemma  D.3)  it  follows  that 

G 

'TGh{a7}C(M(r)). 

Case  RET.  The  derivation  ‘E  has  the  form 

a  =£■  X(H,M,F).cptr(HI(M(esp)),a7)  a  =^,op  a7 

'LL  {a}  ret 

From  ((DC(C)  *  [[ a ]] xj,  )  (H,M,F)),  a  =>■  X(H,M,F).cptr(BI(M(esp)),a7)  and  a  =^,op  a 7  it 
follows  that  [[cptr(H(M(esp)), a7)]] ,j,  and  ((DC(C)  *  [[a7]]^  )  Nextpop(H,M,F)). 

By  the  operational  semantics,  P7  =  (Nextpop(H,M,F),HI(M(esp))).  Then 

1.  P5hC:PG  is  in©; 

2.  ((DC(C)  *  [[ a7 ]] xj,  )  (H,R,F))  is  from  above; 

G 

3.  by  'f/G  b  C :  X¥G,  [[cptr(H(M(esp)),  a7)  ,  and  State  Typing  (Lemma  D.3)  it  follows 

G 

that  M(M(esp))  Gdom(C),  and  it  follows  that  lookup(C,BI(M(esp)),C(BI(M(esp)))); 

4.  by  VFC  I-  C : X¥G,  [[cptr(H(M(esp)),  a7)  ]]^  ,  and  State  Typing  (Lemma  D.3)  it  follows 

G 

that'Fg  h{a7}C(H(M(esp))).  ■ 

Theorem  D.6  (XCAP86  Soundness) 

If  'Pg  h  {a}  P,  then  for  all  natural  number  n,  there  exists  a  program  P7  such  that  Pi — >n  P7. 
Proof  Sketch.  By  simple  induction  on  n  and  using  Progress  (Lemma  D.4)  and  Perservation 
(Lemma  D.5).  ■ 
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